This patch reflects more details such as the percentage value for
downloads maintained in the download queue. This makes this information
easier to display at the GUI.
Issue #4744
This patch replaces the generic "In progress..." message by slightly
more concrete information about the type of operation. This is useful to
distinguish the two steps during the expansion of a partition.
This patch enhances the depot_download subsystem with support for
downloading and querying system images.
The installation ROM support the following two now download types:
<image_index path="<user>/image/index"/>
<image path="<user>/image/<name>"/>
Internally, the depot-download subsystem employs the depot-query
component to determine the missing depot content. This component
accepts the following two new queries:
<images user="..."/>
<image_index user="..."/>
If present in the query, depot_query generates reports labeled as
"images" and "image_index" respectively.
The also tracks the completion of each job depending on the depot-
query results, so that the final report contains a result for each
installation item requested. Prior this patch, the inactivity of the
depot-download manager (indicated by an empty state report) was
interpreted as success. But that prevents the proper association of
results and requested installation items.
Issue #4744
The 'scan' query for depot users used to list the names of depot users.
However, the URL and existence of a pubkey is useful to know when
assembling a GUI menu from this list.
Issue #4744
This patch equips the publish tool to handle system images.
System images reside at <depot-user/image/. The directory contains an
index file that contains the meta information of the available images
in XML form, e.g.,
<index>
<image name="sculpt-pinephone-2023-01-19" board="pinephone">
<info text="initial version"/>
</image>
</index>
To publish a new version of the index:
./tool/depot/publish <depot-user>/image/index
Each system image comes in two forms, a bootable disk image and an
archive of the boot directory. The bootable disk image can be used to
install a new system from scratch by copying the image directly ot a
block device. It contains raw block data. The archive of the boot
directory contains the content needed for an on-target system update to
this version. Within the depot, this archive a directory - named after
the image - that contains the designated content of the boot directory
on target. Depending on the board, it may contain only a single file
loaded by the boot loader (e.g., uImage), or several boot modules, or
even the boot-loader configuration.
To publish both forms:
./tool/depot/publish <depot-user>/image/<image-name>
This results in the following - accompanied by their respective .sig
files - in the public directory:
<depot-user>/image/<image-name>.img.gz (disk image)
<depot-user>/image/<image-name>.tar.xz (boot archive)
<depot-user>/image/<image-name>.zip (disk image)
The .zip file contains the .img file. It is provided for users who
download the image on a system with no support for .gz.
Fixes#4735
Issue #4744
This patch improves the Readonly_file::read method such that the
capacity of the specified buffer is used as upper bound for the read
operation instead of VFS-internal I/O buffer sizes. This relieves the
caller from implementing a read loop in most cases.
As a step away from C-ish use of the API, the patch deprecates the old
'read' method that takes the buffer as char *, size_t arguments.
Fixes#4745
Each time when enlarging the menu view, a new 'Gui_buffer' is
constructed with the new size. At its contruction time, the default
reset background color is in effect, which is evaluated by
'reset_surface' as part of the construction. A custom reset color
takes effect only after the construction. Hence, when the Gui_buffer is
flushed to screen immediately at construction time, the gray default
becomes visible for a short time.
This patch changes the Gui_buffer to accept the reset background color
as construction argument so that it takes immediate effect.
Related to #4592
This patch adjusts the run/image/disk plugin to search for resize2fs in
/usr/sbin, which is not included in the PATH variable on Debian by
default.
Issue #4746
The new utility returns a key code for a passed name and is implemented
by linear search, which is slow but sufficient in situations like config
updates.
Issue #4748
The leading newline in the _capture function confused _filecontent,
which resulted in empty port hashes.
Fixes regression introduced in 437fd21ba0
(issue #4725).
lwip uses a sophisticated reference-counting scheme in chains of pbufs,
which the former manual implementation of read() for TCP data broke.
Using pbuf_free_header() keeps the chain intact and also relieves our
implementation from the burden of "offset" maintenance.
Fixes#4722
Due to lacking hardware access the driver was test with one RTL8188EE
based device, namely [10ec:8179] (rev 01), only. As the access to the
PCI config space is restricted the driver loads the non power-saving
FW and the driver port is therefor only tested with that. The
accesses are documented should we choose to support them one way or
another later on.
The 'wifi.run' run script as well as Sculpt served as testing ground
where the driver worked fine so far.
Fixes#4714.
Check if we are able to submit the Usb packet before attempting to
allocate it. In case the queue is already full we wait until another
pending packet is freed.
Fixes#4701.
Up to now it was only checked if an issued admin command was processed
in a timely fashion. Otherwise it has been treated as failed.
However, the completion-queue entry was not examined and the caller was
not able to access the entry itself. Depending on the command, checking
the completion-queue entry might be necessary, e.g. GET/SET_FEATURE.
Issue #4715.
Since the 'Platform::Device' constructor will defer the creation until
the content of the devices ROM is valid performing the PRP list helper
creation afterwards should be done with valid IOMMU information.
Issue #4715.
Some USB devices (e.g., webcams) fail to deliver their configuration
descriptor early after power-up. Testing revealed that retrying the
requests usually succeeds on second or third attempt.
Fixes#4739
