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.
Change-Id: I5d756cc01dc6225f5cc8b6af90911a3fc7b57cd5
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
GOAL 134000
START 135305
CURRENT 133700
SUCCESS! (ASSUMING IT WORKS -- UNESTED)
Change-Id: Ic3f6ac1dc260578f581ee53458b3e5bb47d313ec
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)
Change-Id: I697b3d0499f85e789c3020bc2133fbe0023f72a2
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.
Change-Id: I90b5c0a1c949283d3102c16734b0b6ac73901a30
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()
Change-Id: Iccb18eebeee5c59f9534df51eb6826876c441762
Note: I left behind lcd_bitmap in features.txt, because removing it
would require considerable work in the manual and the translations.
Change-Id: Ia8ca7761f610d9332a0d22a7d189775fb15ec88a
This allows for a superfloppy that has MBR-like data in the BPB.
this solves FS#12294 while allowing arbitrary partition types.
Change-Id: I53880fe7dd53e5015f5f15be0ddba11105fcd778
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 <torne@wolfpuppy.org.uk>
Change-Id: I558d4287189408c513dfbca49e13906cdb7918b1
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 <torne@wolfpuppy.org.uk>
Change-Id: I3ea8d437a79f9da270f9d119cc670e472331a9da
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
Change-Id: I0f786aa0c8721e21cba607366775be3e3c0cf474
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.
Change-Id: Icdbe26ec6ede564861cc01ac4add76a12b00ecd5
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
needed.
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.
Change-Id: I6dae8624d3208e644c88e36e6a17d8fc9144f988
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
Change-Id: Ic4d1439334588f999c9071235430c42df2af5cc4
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
Change-Id: I475073419b647639ef1eeaa3b9213e4e1067c0db
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.
Change-Id: I11820c1968ed7b20aa00e106a022c1b864b03d21
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.
Change-Id: I6fd325f22845029a485c502c884812d3676026ea
New support as well as some buggy support fixed.
Still no floating point support if ever that would be desired.
Support (*):
* 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
at it.
Could smush it down in size but I'm gonna get over the binsize
neurosis and just the let optimizer do its thing.
Change-Id: Ibdc613a9b6775802c188b29b9dd46c568c94f7c3
Adds the ability to load firmware from other drives on MULTIVOLUME targets
Mihail Zenkov <mihail.zenkov@gmail.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/
NOTES*
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
first.
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
internal drive
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
well.
Change-Id: Iada3263919f6bcad7d0d7d8279b4239aafa07ee9
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
Just need to check prev and next for NULL to know whether to mess
with the head and/or tail pointers.
Change-Id: I0aee057111e11735b7806e7214af0a6038f0ab53
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
MAX_TINYNAME+1.
Change-Id: Ic789376b8575bab9266fcd54c610db0961de5d7f
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.
Change-Id: Ife133e0be0dc0dfd53a4de119f70dba014c7ee68
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
headers.
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 ;)
Change-Id: I9ba183bf58bd87f5c45eba7bd675c7e2c1c18ed5
* 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
parent.
* 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
Change-Id: Iff747b624acbb8e03ed26c24afdf0fc715fd9d99
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.
Change-Id: I26ccf219c382d7caf1424b5ddddc4793e74cb390
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
minor filtering.
Change-Id: Ic8bcfba718ebf4228bdc45de3088af1974820557
Critical reminders about the reasons path_dirname() and
path_basename() do certain things with a given kind of input and
how to interpret them.
Change-Id: I4e6ad29476bdd30abfb644f9360cc7dfd86298df
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
long term.
Change-Id: I09de30ff8174ad1d14eeeb9539bd23fb51b9e31a
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.
Change-Id: Ibc8f26c1d1eca672c753280b49fd8259fde51047
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.
Change-Id: Idd0ded6bfc9d9f48fcc1a6074068164c42fcf24a
FF_PROBE should leave nothing for caller to clean up whether
testing only the cache or permitting disk access. Less to worry
about.
Change-Id: Iea5aa3c1ae7f9025a9de528b127f08e490154048
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.
Change-Id: I7e2a9910b866251fa8333e1275f72fcfc8425d2d
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
wrong.
Change-Id: I68e0875b04bb0ab6cdead0fdf535144b9c1bc13e
ll_insert_next() and ll_remove_next() can be done more elegantly
by adding a level of indirection to reference the 'next' pointer.
Change-Id: If3ab2bc2a659b517c793749cfa9088938ae08d0d
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.
Change-Id: Ic0800cea79c59563b7bac20f8b08abb5051906c7
