|Age||Commit message (Collapse)||Author||Files||Lines|
Before this was just implemented inline wherever it was needed. Now
it is provided as 2 inline functions in a header called checksum.h.
There should be no differences in actual behavior.
if idx == 0, get_idx_dcvolp() will return NULL.
REMOVED FROM ALL NATIVE BOOTLOADERS:
finish removing the text scrolling
pare down printf to a minimal subset (%c %s %l %d %u and %x(%p))
remove diacritic and rtl language support
SUCCESS! (ASSUMING IT WORKS -- UNESTED)
This reverts commit 31fc46ded69be7438cca2ba2c2b93c1f200165a6.
Firmware now includes rudimentary redirect functionality
but this only supports /.rockbox in the root of the device
This patch allows loading external drive and directory into root namespace
Root Redirects can now be put into different folders
For instance placing '/_test' into SD1/rockbox_main.<playername>
will redirect to /<1>/_test/.rockbox
Debug menu>Bootdata now has root directory listed in addition to RAW Bootdata
Redirect root work from Michael Sevakis g#1556
Redirect will be updated if code refactor is ever done
Requires Multiboot bootloader (already in main)
Provide definitions for the macros:
* RB_ROOT_VOL_HIDDEN(v) to exclude certain items from the root.
* RB_ROOT_CONTENTS to return a string with the name of the
directory to mount in the root.
Defaults are in export/rbpaths.h
It's a bit much for those that don't need the full functionality.
Some conditional define can cut it back a lot to cut out things only
needed if alternate root mounts are required. I'm just not bothering
yet. The basic concept would be applied to all targets to keep file
code from forking too much.
I never added multiboot awareness to ROLO
When a new firmware file was loaded [Bootdata] would not be
copied to the new instance resulting in the firmware
running off the internal drive till next reboot
Bootloaders shares the rb-loader code but should not be
affected by the removal of static from write_bootdata()
Note: I left behind lcd_bitmap in features.txt, because removing it
would require considerable work in the manual and the translations.
This removes all code specific to SH targets
This allows for a superfloppy that has MBR-like data in the BPB.
this solves FS#12294 while allowing arbitrary partition types.
If we aren't going to check for the partition type, we don't need the array of
known FAT partition types.
Original Author: Torne Wuff <email@example.com>
Instead of only mounting partitions with a FAT partition type, try any
partition that isn't type 0 (unallocated) or 5 (extended). This makes it easier
to reformat SDXC cards which have the exFAT partition type, and also brings us
in line with pretty much every other OS at this point. Anything with a
valid-looking FAT superblock will get mounted.
original author: Torne Wuff <firstname.lastname@example.org>
Stop gap till I get a chance to work on the root folder stuff
Makes whatever volume marked by bootdata.boot_volume
the base or root volume, mounts all other volumes after
the specified boot volume.
Has the effect of swapping the SD card to the slot for internal
and Internal storage is mounted as the Sd-card.
Does not honor root redirect -- uses .rockbox folder in the root of boot volume
The Quake plugin is the only code that actually relies on float
formatting. Because Quake only runs on targets with huge memory
anyway, limiting their formatting to just those targets will minimize
the increased memory use in the core.
Wanted to see how gnarly it is to do.
Big number handling could be done with better algorithms
since it can get a bit slow with large integers or tiny
fractions with many lead zeros when only a few digits are
Anyway, it supports %e, %E, %f, %F, %g and %G. No %a or long
double support seems warranted at the moment.
Assumes IEEE 754 double format but it's laid out to be able to
replace a function to handle others if needed.
Tested in a driver program that has a duplicate vuprintf and
the content was pasted in once it looked sound enough to put
up a patch.
when precision is not specified memchr recieved -1 for count
count is unsigned so it looks in a potentially very large area
for a terminator and returns this whole area if \0 is not found
Instead we should use memchr when precision is specified
and if precision is not specified use strlen
Fixes 60+Mb Config.cfg files
is_diacritic is used for pretty much all of the text display sizing
Timing here matters, so important it uses a
priority buffer in order to cut down on searching the database.
This patch is verified functionally equlivalent but
saves 80 bytes and is ~20% faster for the clip+ I tested it on
Several things were done:
Optimizing the copy loop for the priority buffer
Globbing some operations together
but the main one has to do with the database structure its self
Rather than a bit packed struct it combines the lower 8 bytes into
one value [info] and uses flags to access the values instead
patching clip+ OF.
This reverts commit 01c6dcf6c7b9bb1ad2fa0450f99bacc5f3d3e04b.
The hack isn't used in duke, so having it is redundant.
This ports Fabien Sanglard's Chocolate Duke to run on a version of SDL
This is just a quick and dirty way to get %f formatting to work for
some games. It works.
Avoids a call to write() for every output character. It doesn't
need to be very large to have a great effect on speed and realize
most of the potential.
Instead of checking ticks, set a sticky dirty flag that indicates
that the RTC needs to be read. This gives a timely update and more
accurate readout without actually reading the RTC until it changes.
The implementation should atomically read the flag and clear it.
Setting the flag would typically happen in an RTC tick ISR.
New support as well as some buggy support fixed.
Still no floating point support if ever that would be desired.
* Flags: '-', '+', ' ', '#', '0'
* Width and precision: 'n', '.n', '*' and '.*'
* Length modifiers: 'hh', 'h', 'j', 'l', 'll', 't', 'z'
* Radix: 'c', 'd', 'i', 'n', 'o', 'p/P', 's', 'u', 'x/X'
(*) Provision exists to switch lesser-used stuff on or off or when
certain functionality isn't desired (bootloader?). The compulsory
radixes are everything but 'o', 'n', 'p/P' and 'x/X' with length
modifiers being optional. The default setup is 'l', 'z', 'c', 'd',
'p/P', 's', 'u', 'x/X'.
* Move fdprintf() to its own file. It was in a strange place.
* Make callers compatible and fix a couple snprintf() bugs while
Could smush it down in size but I'm gonna get over the binsize
neurosis and just the let optimizer do its thing.
Adds the ability to load firmware from other drives on MULTIVOLUME targets
Mihail Zenkov <email@example.com> had posted a hard coded patch
to allow this on several Sansa players, I made it more universal
Redirect file rockbox_main.<name> should placed in root of
drive you would like to be main, if this file empty or there a single
slash '/' firmware will be loaded from /.rockbox in root of this drive
If instead a /<*DIRECTORY*> is supplied in rockbox_main.<name> then
firmware will be loaded from /<dir>/.rockbox/
The directory can have multiple levels however..
leading slash MUST be included
trailing slash can be omitted
(eg. /test/.rockbox would be simply '/test' in the redirect file)
Redirect file will not work on internal drive (whatever is default boot drive)
Volume with the highest index containing redirect file will be loaded
Firmware file is checked for boot data region, if missing, firmware
image will not be loaded.
On failure or if no redirect file is found load will fallback to
Currently only Sansa Fuze+, Sansa Clip+,
Sansa Clip Zip, Sansa Fuzev2, and Sansa Fuzev1 are implemented.
Players (with HAVE_MULTIVOLUME)
will need #define HAVE_BOOTDATA and #define BOOT_REDIR "rockbox_main.<name>"
added to their config file
boot_data is implemented in crt0.s file (See g#1552)
ARM and IMX233 have aleady been implemented
Once these conditions are met <HAVE_MULTIBOOT> will be defined by config.h
Partitions on the drives are able to have a redirect as
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
Just need to check prev and next for NULL to know whether to mess
with the head and/or tail pointers.
There's only a need to check every MAX_TINYNAME+1 bytes and that the
last character of the needed size 0xff in order to verify the size
of the block since the minimum indirectly-stored string is
When dircache scanning is happening in the background, the user
can shut down the device before it is complete. Then, reset_cache()
sets size to 0 before it is copied to last_size at the end of
build_volumes(). When saved last_size is zero, scanning happens in
the foreground during next startup.
Avoid shrinking the size if the build is suspended.
Many includes of fat.h are pointless. Some includes are just for
SECTOR_SIZE. Add a file 'firmware/include/fs_defines.h' for that
and to define tuneable values that were scattered amongst various
Remove some local definitions of SECTOR_SIZE since they have to be
in agreement with the rest of the fs code anyway.
(We'll see what's in fact pointless in a moment ;)
* 8 bits is enough to allow 260 character base names when five
bytes is the minimum indirect storage size (0..255->5..260).
* Don't truncate anything that's too long as that can lead to
bad behavior, simply don't include the offending entry in the
* Set the .tinyname flag to 1 by default to indicate that
the entry's name doesn't need freeing. Clear it only when
allocating indirect storage.
* Rename some things to help catch all instances
Moving binding from queued to resolved was messed up if it was the
first queued one and there were other resolved files open at the
time of resolving it.
Dircache info for a directory about to be recursively scanned should
be filled before opening it. Would only affect a directory if it
happened to be opening while it was being initialized.
These flags aren't stored for an open file because they're simply
actions for open() to take, corresponding to O_CREAT and O_EXCL.
Just pass the oflag argument along to the deeper call, with some
Do a few other changes to dircache and file code flags to
accomodate its demands.
Critical reminders about the reasons path_dirname() and
path_basename() do certain things with a given kind of input and
how to interpret them.
If a volume root was open at the beginning of a build, its dircache
reference wouldn't be resolved on an already open volume root
directory because the call to do it was simply omitted. Nothing
horribly bad unless a root were opened at mount time and kept open
volume_onmount_internal() was being given the next volume to mount
instead of the one just mounted. Only dircache was being notified
for now, which always attempts to scan everything that needs to be
rebuilt, currently making the volume parameter value immaterial.
Put things in the right place and also set the disk sector
multiplier before notifying anybody of the new volume.
Some drivers set tm_wday just fine and do not need it coerced to
be correct. Others set tm_yday, so don't overwrite what the driver
sets; just zero it inside if it can't fill the field. Move calls
to set_day_of_week() to the sorts of drivers that presumably
required the hammer (FS#11814) in get_time() where the weekday
isn't locked to the date.
FF_PROBE should leave nothing for caller to clean up whether
testing only the cache or permitting disk access. Less to worry
The file system rework introduced incompatibility between dircache
and the tagcache ramcache and playlist dircache path caching. This
update makes changes to filesystem code to reintegrate all that.
It also fixes a couple bugs that were found when vetting all the
code. The filestream cache was being reset without regard to
the stream even if it was shared in write mode (made work of
.playlist_control). Better handling of unmounting gives files a
better go at force-closing them without risk to disk integrity.
Did some miscellaneous pedantic changes. Improved efficiency of
testing a file's existence (a little) since the path parser will
be shared between file code and parsing for the sake of finding
dircache references, not duplicated as before.
This commit doesn't reenable said items just for the sake of
keeping changes separate and related.
Plan for the next is to enable dircache again for the playlists
(easy peasy) and reenable tagcache ramcache but *without* the
dircache path caching because it's rather substantial to change
in itself. The ramcache will still function without dircache.
Logic left over from before switching from NULL-terminated to
counted strings would prevent a single-byte tiny free block gap
from being properly reclaimed into free string bytes.
Due to rarity, not as disasterous to functionality so much as
ll_insert_next() and ll_remove_next() can be done more elegantly
by adding a level of indirection to reference the 'next' pointer.
Some changes in behavior were made with filesystem code commit
for the sake of compatibility that changed expected behavior.
* Restore substitution of drive spec in fully-qualified DOS paths
with the playlists's volume spec (or root on univolume targets).
Drive-relative paths of the form "c:foo" (no separator after
':') will be treated as purely relative.
* Restore old behavior of preserving leading whitespace in the
source path and trimming only trailing tabs and spaces.
* Multivolume: Volume substition on fully-qualified UNIX/RB paths
has NOT been reintroduced (and perhaps wasn't intended in the
first place). They will not be modified because there is no
ambiguity to resolve. Doing so would prevent a playlist on
external storage from referencing a file on main storage without
qualifying it with "/<0>...".
* Plain relative paths are and always have been interpreted as
relative to the location of the playlist.