strlcpy returns the length of the string that would have been copied
had there been sufficient space basepath_max might still be
larger than buf_size yet smaller than len
which would result in a null terminator being written past buf[buf_size-1]
Change-Id: I43e8ba9f72ea35bfe4f759ecd102c2e4bd26eb75
Comments and notes are converted to UTF-8. Already broken multibyte characters are fixed using common sense.
This patch contains no code changes.
Change-Id: Ia511ab84936cb2495ac17309493a9b98727a7902
* Make the partial sector logic a little clearer (no functional change)
* Corrections for debugging messages
* Also use MAX_VIRT_SECTOR_SIZE in BOUNCE_BUFFER calculations
Change-Id: I89363824b092b2e3bddd5e0f75bf81200c9bc513
Normally, if a device uses larger physical sector size than the logical
size and supports so-called "512e" mode, we let the device deal with
partial sector reads/writes.
However, if MAX_VIRT_SECTOR_SIZE is defined, we support
partitioning/filesystems that use a larger "virtual" sector than the
logical sector. typically this matches the physical sector size of the
drive, which means that despite a small logical sector size, all I/O
is done in terms of the physical sector size.
Therefore, when MAX_VIRT_SECTOR_SIZE and MAX_PHYS_SECTOR_SIZE are
enabled (currently only ipod5g and ipod6g), prefer software-based
partial sector I/O.
Change-Id: I0815ad0a2f987b89bb2debfbf3d0ed64cdf85525
This isn't strictly needed for FAT32, but the core file cache code
needs to be able to reference >32bit sector addresses.
Change-Id: I57838f1228c1d45f6a8c4755c5d1f9063c13b3dd
Normally, we figure out the virual sector size from the filesystem info.
However, if there's no filesystem, we fall back to the hardware's
logical sector size.
Some device firmware (eg ipod5g/6g) need their partition tables set up
with larger-than-logical sector sizes; this way we can present the
"correct" sector size to maintain interoperability with the stock
firmware and make it so that the drive can still be properly partitioned
from within rockbox.
This patch adds support for DEFAULT_VIRT_SECTOR_SIZE. Nothing uses it yet.
Change-Id: Iae746a50ffc37c51abb2c9b82d3c4596f1fa7559
When enabled this allows 512n and 4Kn drives to be used with a single build.
(So far all ATA SSDs use 512 byte logical sectors)
Change-Id: I902d2318ca8abb581699c0bca68d6e3ec227d064
Only used if MAX_LOG_SECTOR_SIZE is defined
This allows a single build to seamlessly work with (eg) 512B or 4K sectors.
Change-Id: I85d2a6612afca6a1d7a3bd49c588b5745ab2b220
Fuze+, native Sonys, and some of the Zens use 2K sectoring from
the partition/filesystem perspective, even though the underlying
storage used 512-byte sectoring.
Change-Id: I247d8cae2582c63ec1d4dda0fb225b1a25c8e16a
This allows a single build to support ATA drives with (eg) 512B and 4K
logical sector sizes. This is needed because ATA drives are user-
replaceable and we don't know what could get plugged in.
* Add disk_get_log_sector_size() API (no-op for non-ATA storage)
* Mostly a no-op if MAX_LOG_SECTOR_SIZE is not enabled
* Sanity-check that storage's logical sector size is not larger
than what we're built for
NOTE: Other layers (eg ATA, FAT, etc) still need to be made aware of this.
Change-Id: Id6183ef0573cb0778fa9a91302e600c3e710eebd
* Create new 'sector_t' type alias:
* uint64_t for all targets with HAVE_LBA48 or HAVE_SDUC
* unsigned long for the everything else
* Alter all storage APIs to use sector_t instead of 'unsigned long'
* Alter Volume/Partition/storage info structures to use sector_t
* Disk cache converted to sector_t
* ATA Core:
* convert to using sector_t for sector addresses and drive sizes
* Always fill out upper 16 bits of LBA48 addresses
* IDENTIFY INFO is fixed at 512 bytes, not SECTOR_SIZE
* USB mass storage:
* convert to using sector_t for sector addesses and drive sizes
* Implement READ_16/WRITE_16 for LBA48 addresses
* Convert FAT code to use sector_t for all sector references
* output_dyn_value() now accepts int64_t instead of 'int'
* Corrected "rockbox info" to work for (MULTIVOLUME & !MULTIDRIVE)
* Better reporting of disk and (logical+physical) sector sizes in debug info
* Detect SDUC cards and report on storage debug_info screen
To-do: SDUC
* Refactor SD core to remove duplicate code in every driver
* Card probe and init state machine
* Implement core SDUC support
* SD2.0 needs to be 2.0+ (fixed for jz47xx and x1000)
* Host and Card ID (ACMD41)
* 32-bit addressing for all read/write/erase operations (CMD22)
* ADD SDUC to target device drivers, defining HAVE_SDUC as appropriate
Change-Id: Ib0138781a0081664d11511037685503df1b93608
...So just move that call into storage_init and be done with it!
Hopefully this doesn't cause any functional regressions.
Change-Id: I08700fbd1613638606a23ee3a0c2149123c2c24a
This should actually be strip_extra_leading_separators() but
its not used anywhere else yet and I don't see enough callers
in core to make it worth the extra overhead
Change-Id: Icdd292869b4198bed7725c51820f6b2111ad739d
it appears this is false positive but its compliaining
about the uninitialized pointer,
not a bad idea to initialize pointers to NULL anyway
Change-Id: I5832a19ab13971c7d55580694eef70591a3a9acb
This reverts commit 0c737d3b2e.
Reason for revert: Not really a concern as open_stream returns an independent buffer since g#566
Change-Id: Idbd2f4a7cc2ea6362b7714629469eeb7b3d19b3b
v1 passes the drive and partition number of the boot volume
instead of using the volume number. The volume number isn't
reliable because the same filesystem might get a different
volume number once the firmware is loaded, which will cause
the firmware to use the wrong root volume and fail to locate
the correct .rockbox directory.
Using drive and partition numbers avoids this issue because
drive numbering is fixed and determined by the target.
Change-Id: I7e68b892d9424a1f686197a6122e139b438e5f7e
Instead of verifying the CRC before every access of the boot data,
verify the CRC once at startup and set a flag to indicate the boot
data is valid.
Also add a framework to support multiple boot protocol versions.
Firmware declares the maximum supported protocol version using a
version byte in the boot data header. The bootloader chooses the
highest version supported by it and the firmware when deciding
what boot protocol to use.
Change-Id: I810194625dc0833f026d2a23b8d64ed467fa6aca
The standard load_firmware() function is used on targets which
use the "scramble -add" method for generating Rockbox binaries.
While it tries to be a bit more generic and allows the CRC/data
offsets to be placed anywhere in the file, there are no targets
which actually need this flexibility, because they are all using
plain old "scramble -add".
So we can actually simplify load_firmware() and remove defines
from the target headers. All the targets used CRC offset = 0 and
data offset = 8, except for a few which I assume never supported
ROLO or were never tested -- eg. samsungyh820: the CRC and data
offsets cannot both be 0.
The actual motivation for this is removing the calls to lseek(),
which can help make bootloaders a tiny bit smaller, as lseek is
typically not used anywhere else in bootloaders.
Change-Id: Ic2d01e5b75a32e88363f085e3e839146a0710bf4
Turn off legacy codepage handling in the filesystem code for
bootloaders, and support ISO-8859-1 (Latin-1) only.
This only affects DOS 8.3 filename parsing when FAT32 long
names are unavailable; long names are Unicode and can always
be decoded properly regardless of this setting.
In reality, bootloaders never supported codepages other than
Latin-1 in the first place. They did contain the code to load
codepages from disk, but had no way to actually change the
codepage away from Latin-1.
Compiling out this useless codepage handling code frees up
precious space for very size-constrained bootloaders like the
Sansa e200v2.
Change-Id: I26b049dd648fed4a0cc61fa938faa84e9816ab7d
Buflib pinning was introduced here in 1718cf5.
If the device has to immediately shut down after booting
because of a low battery, the directory cache may be disabled
by the time core_unpin() is reached.
Its handle will have been reset to 0 in that case, triggering
a panic message due to an invalid buflib handle.
Change-Id: Ie34c3f7142d8406b66277ef185bc9ecf387d7295
When the sd card is mounted into the root namespace the database
picks up files through both paths
previously we hid the mounted drive but this causes issues with users
databases when the drive letter changes
Adds a way to keep track of volumes mounted in the root namespace
Hides the enumerated volume in root
Database:
we can just parse the root directory ('/') and get to any mounted
volume but we can also enumerate a volume in the root directory
when this occurs it leads to multiple entries since the files can
be reached through multiple paths ex, /Foo could also be /SD1/Foo
Instead we will attempt to rewrite the root with any non-hidden volumes
failing that just leave the paths alone
Change-Id: I7bdba8cfaf63902d2a3852d28484bcf8ca317ebd
remove some duplicated strings previously allocd off the stack
just removing string duplications that are easily handled with truncation
now available with path_append_ex()
this also has an advantage of less stack used in worst case scenarios
Change-Id: I3a43e33ef8a8c36599e4c6c036a0ccdd8ed0c883
In my opinion this API is just not very useful - design is kind
of questionable. There are hidden limits on the struct size and
bugs on 64-bit platforms due to assuming sizeof(long) == 4.
At the end of the day, the only major user was the tagcache and
it's actually less code size to do endian swapping manually.
Change-Id: I451c7f1a10cf3e28744c32c0f1f39a710d5cc100
