We used 16-bit variables to store the 'character code' everywhere but
this won't let us represent anything beyond U+FFFF.
This patch changes those variables to a custom type that can be 32 or 16
bits depending on the build, and adjusts numerous internal APIs and
datastructures to match. This includes:
* utf8decode() and friends
* font manipulation, caching, rendering, and generation
* on-screen keyboard
* FAT filesystem (parsing and generating utf16 LFNs)
* WIN32 simulator platform code
Note that this patch doesn't _enable_ >16bit unicode support; a followup
patch will turn that on for appropriate targets.
Appears to work on:
* hosted linux, native, linux simulator in both 16/32-bit modes.
Needs testing on:
* windows and macos simulator (16bit+32bit)
Change-Id: Iba111b27d2433019b6bff937cf1ebd2c4353a0e8
We've received multiple reports from users of 6th gen iPods where we
fail to find any mountable partition. A user was able to supply an MBR
dump, which showed that the "type" listed for parition 0 was set to 0x00
(ie "unused"), leading us to (correctly) completely ignore that entry.
However, it looks like the stock firmware ignores the type and
unconditionally uses the first entry even if it's nominally "invalid"
So, to deal with this, always try to mount partition 0 if it is not one
of the two "extended partition table" types. If that speculative mount
succeeds, we now treat it as type 0x0c (Fat32 w/LBA) internally.
Note that this will not allow the partition to be mountable over USB, as
the MBR is still incorrect, leading the host OS to ignore the partition.
Further complicating things, the stock Apple firmware always constructs
a fake MBR to hand to the host!
To prevent user confusion with these devices, we may consider faking the
MBR too; alternatively we could correct the MBR and write it back to
disk, perhaps via a debug menu option.
Change-Id: I1e9392d20401eb94ecc6d70263fb0e45392a9bd4
We used 16-bit variables to store the 'character code' everywhere but
this won't let us represent anything beyond U+FFFF.
This patch changes those variables to a custom type that can be 32 or 16
bits depending on the build, and adjusts numerous internal APIs and
datastructures to match. This includes:
* utf8decode() and friends
* on-screen keyboard
* font manipulation, caching, rendering, and generation
* VFAT code parses and generates utf16 dirents
* WIN32 simulator reads and writes utf16 filenames
Note that this patch doesn't _enable_ >16bit unicode support; a followup
patch will turn that on for appropriate targets.
Known bugs:
* Native players in 32-bit unicode mode generate mangled filename
entries if they include UTF16 surrogate codepoints. Root cause
is unclear, and may reside in core dircache code.
Needs testing on:
* windows simulator (16bit+32bit)
Change-Id: I193a00fe2a11a4181ddc82df2d71be52bf00b6e6
Moves special folders (like .rockbox) on top and makes filenames sorting look more consistent with folders sorting. See https://forums.rockbox.org/index.php/topic,55303
Change-Id: I6ffd9b3ea0acfcbab69f09415f4e9f53737e7769
GPT superblocks are located at sector 1 and max_sector-1. If the system
uses a "virtual" sector that's larger than the drive's logical sector,
we need to map those virtual sector numbers to the drive's logical
sector.
If DEFAULT_VIRT_SECTOR_SIZE is defined, try that multiplier as well
as the standard multiplier of 1.
It's not practical to try every intermediate value so instead, if
DEFAULT_VIRT_SECTOR_SIZE is defined, try that as well as the standard
multiplier of 1.
This still leaves a handful of targets that don't set DEFAULT_VIRT
but do set MAX_VIRT.
Change-Id: I3accffcb97436b043836e072bfc620318a9b1230
Basically the GPT is supposed to live at sector 1, but a backup copy is
stored on the final sector.
This gives us a little bit of extra flexibility on systems that might
require sector 1 for other things, but in any case it's a more robust
arrangement.
Change-Id: I8925ffc743629cf2eba51861042492e35b41664b
We normally create a table of the partition sizes/types present
on a drive. Howeever, if the drive is set up as a "superfloppy",
where there is no partition table and a single filesystem starting
at sector 0, this "pinfo" table is not populated.
So now, populate the pinfo table with a single entry that matches
the filesystem type, start, and size.
Change-Id: Ifa8760909109d67ff96481b1fc7f26c64280a00a
-1 could be supplied unintentionally from user code when utf8_size is computable value
Fixup for 004304dc and 1f548f74
Change-Id: I93008ea289bdb134f051975c25b0db9d0e64b823
characters less than the first diacritic in the symbol table (0x300)
return false after checking the MRU table
we gain some performance by eliding the function call all together if less than first diacritic
Change-Id: I02c14e350eb168eca808523affad443cd43888b4
I pushed the wrong version of the function it was an experiment
on resetting haystack past the searched string but it is missing the
rest of the logic and therefore misses strings that should match
Change-Id: I23391d2e753840bfeaab8e26d9987198272fe7b8
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
