* Introduce CPU quota for driver subsytem (needed by sd_card_drv)
* Introduce CPU quota for runtime subsytem and nic_drv (needed by fec_nic_drv)
* Increase CAP quota for inspect terminal slightly
* Add sculpt packages for imx8q_evk
Fix#3958
* Introduce sculpt-[board] specific package
* Move rtc driver into managed drivers sub-system
* Name nic_drv in a generic fashion in sculpt_manager
* Copy over pc-specific config files only when building for PC
Ref #3958
Originally the outgoing buffer was flush when the terminal was
detached. Since we cannot do that at this point, make the flushing
part of the common cleanup procedure.
Issue #3682.
Rather than calling 'ssh_disconnect' from within the Terminal session,
flag the detached terminal in the session and let the event loop do the
cleanup. Otherwise it might happen that the 'ep' (handling the Terminal
session) as well as the 'pthread.0' (executing the ssh event loop) end
up both triggering the cleanup concurrently.
Issue #3682.
In case of arm_v7a Kernel::call64 the syscall will use both r0 and r1 as
output registers. Unfortunately the inline asm does not reflect this and
only r0 is explicitly specified as output. GCC manages to produce output
which we'd like to see. Clang on the other hand takes adventage of the fact
r1 should not be touched by swi and produces fewer instructions which do
what the code describes, but not what we actually want.
Basically the code which we want and is generated by GCC is:
svc 0
mov r2, r0
mov r0, r1
mov r1, r2
bx lr
Clang on the other hand generates correct assembly given the code, but
incorrect given what the function is supposed to do:
svc 0
mov r1, r0
mov r0, #0
bx lr
Both GCC and clang generate the same, expected assembly output when r1
is marked as output register from the inline asm swi call.
Fixes#3951
Clang correctly asserts this private member variable is not used
anywhere in the code. I'm not sure what the intention of the code is,
might be this is a part of some unfinished feature. This patch just does
the minimum amount of work to allow the code to build with clang. If
required I can also drop the parent_levels constructor argument and
clean up the call sites.
Issue #3950
The msg argument in Genode::Rpc_dispatcher::_read_arg is not used. GCC
does not care about this, but clang does and prints a warning regaring
this. Silence it by removing unused argument name.
fixup! base: Silence unused arg warning in rpc_server.h
The CBE repository contained a lot of Genode-specific code despite the fact
that the CBE core logic is not bound to Genode in any way. Therefore the
Genode-specific CBE code is moved to the 'gems' repository to form part of
Genode mainline. The remaining CBE code becomes a port in Genode instead of
being invoked as sub-repository.
The commit combines the following work steps:
* add all files removed from CBE repository
* add CBE port files
* make all CBE libs and targets build again
* make all CBE run scripts succeed again
* make all CBE recipes build again
* make CBE autopilot succeed again
* let CBE autopilot use 'libsparcrypto' contrib dir and Genode build dir
instead of '.ci' dir in CBE contrib dir (remove '.ci' dir from CBE repo)
* let CBE autopilot always check for all ports
* make CBE autopilot directly executable
* fix license headers in all Genode CBE files
* remove unused VFS replay component
* remove unused CBE test
* remove unused external crypto
* remove unused files in run dir
* remove unused external trust anchor
* add cbe_tester test to autopilot list
* get rid of directories 'include/cbe_*' and 'include/utils'
Fixes#3937
The control area is constructed during session creation and the caller can
handle the Out_of_* exception by increasing the quota by the next attempt.
Fixes#3917
Log a warning when the lwIP VFS plugin queues a read while waiting
for an interface to become ready. By comparision the Lxip plugin
has the same behavior but a more verbose initialization process.
Fix#3920
Account for the situation where the driver is started while the HP
is already plugged in and configure the mixer accordingly.
Thanks to Peter for the patch.
Issue #3929.
Due to what seems like a copy-and-paste error, the wrong union member
was used to compare the label. Fortunately, as both structs have the
same memory layout that did not result in any issue.
Issue #3929.
