The launcher.run scenario was last updated mid-may of the recently
developed cap-quota accounting (before all cap types were covered).
Hence, the quotas used in the scenario are too low. This patch adjusts
the values such that the scenario can be started on NOVA on Qemu. It
also fixes a warning about a deprecated way of configuring the
report_rom component.
Thanks to Jörg-Christian Böhme for reporting!
- Update FatFS port from 0.07e to 0.13
- Multi-device support
- Basic test at run/fatfs
- Adaption of existing components
Note, ffat is now consistently renamed to fatfs.
Ref #2410
rm_fault.run triggers write on read-only ROM provided by core, which
fails without this patch:
arm - "raised unhandled data abort"
x86 - (silent/invisible) busy loop because write fault gets never resolved
The run script did not consider the routing for the environment ROM
sessions for the test-iso component. It routed all ROM sessions -
including the ones for the executable and the dynamic linker - to
fs_rom. The patch also adds the cap quota definitions required since
version 17.05 and fixes a whitespace inconsistency between the test
program and the run script.
Thanks to Steven Harp for reporting!
This is expected by hardware terminals, ie., terminal programs connected
to null-modem serial connections. Otherwise, the next line starts at the
column right after the last line.
Platform_pd "_pd" uses a allocator for, which relies on the mapped RAM
dataspace within core. Unfortunately the RAM dataspaces are already freed up
during _ram_ds_factory destruction, which may lead to trouble if accessed
afterwards.
Issue #2451
relocation is required, to avoid overlapping phdr in the elf binaries, but
sel4 will fail to boot if bender relocates the images at the end of physical
memory. Limit the physical relocation address to a fixed 256M value, so that
sel4 will work.
Issue #2451
The new version of the test exercises the combination of fs_report with
ram_fs and fs_rom as a more flexible alternative to report_rom.
It covers two corner cases that remained unaddressed by fs_rom and
ram_fs so far: First, the late installation of a ROM-update signal
handler at fs_rom right before the content of the file is modified.
Second, the case where the requested file is not present on the file
system at the creation time of the ROM session. Here, the ram_fs missed
to inform listeners for the compound directory about the later created
file.
This patch ensures that fs_rom delivers a ROM-update notification in the
case where the underlying file was changed in-between requesting the
initial ROM content and registering the signal handler.
With the introduction of the CONTENT_CHANGED notifications delivered via
the packet stream, the assumption that no more than one READ packet is
in flight at all times does no longer hold. If the fs server responds
to a CONTENT_CHANGED packet while the fs_rom expects the completion of a
read request, the '_update_dataspace' method would prematurely return,
leaving the dataspace unpopulated. This patch solves the problem by
specifically waiting for the completion of the read request.
