If you like BoxMatrix then please contribute Supportdata, Supportdata2, Firmware and/or Hardware (get in touch).
My metamonk@yahoo.com is not reachable by me since years. Please use hippie2000@webnmail.de instead.

0
U

Property:cpunet.ko

From BoxMatrix


BoxMatrix >> Shell-Commands >> cpunet.ko @ BoxMatrix   -   IRC-Chat   -   Translate: de es fr it nl pl
News Selectors Models Accessories Components Environment Config Commands System Webif Software Develop Lexicon Community Project Media

Startup-Scr Hotplug-Scr BusyBox-Cmds Bash-Cmds AVM-Cmds Chipset-Cmds Linux-Cmds Shared-Libs Kernel-Mods Research

Kernel-Module

Note that Kernel 2.4 and builtin *.o modules have been renamed to *.ko for an easier comparison.

Goto:   GPL-Browser  -  Dependencies   -   Model-Matrix   -   Symbols   -   SMW-Browser

Details

cpunet.ko is the AVM driver for the cpunet or cpunet0 network interface used for Inter-CPU communication on models
with a Falcon or Seale SoC, see the Model-Matrix below.

On the Falcon cpunet interconnects the Bootcore Linux (prxB, secure) and the Interaptiv Linux (prxI, unsecure).
On the Seale cpunet interconnects the Bootcore Linux (grxB5, secure) and the Interaptiv Linux (grx5, unsecure).

cpunet.ko is loaded by rc.cpunet which is started by cpunet.service.

Full quote of the fw 7.50 README:

This driver spawns a netdevice named "cpunet" that allows communicating between
two systems using the well known socket API. The requirement for this is that
these two systems share some memory.

See the "avm,cpunet.txt" device tree binding file for more information on how
to integrate the driver.

IPv6 only:
        This device only supports IPv6. IPv4 or even non-IP protocols will not
        work. This is for two reasons:
        1.
                IPv6 has support for unique local addresses. This
                avoids clashes with user selected subnets on the lan bridge.
        2.
                As a consequence of 1, and because we do not need layer2
                addresses, no layer2 headers are generated.

Usage:
        Add IPv6 addresses on both sides (peferably ULA)
        and just use it as any other network device.

Latency:
        Icmp round trip time is comparable to loopback on grx
        (< 200 µs difference).

TCP Performance:
        The performance with iperf3 tcp is 110MBit/s. The bottleneck here is the
        bootcore which is at 100% CPU while the interaptiv is mostly idle.
        Sendfile from bootcore to interaptiv performs at 170Mbit/s.
        Despite being at its limit the bootcore stays responsive because of the
        implemented interrupt mitigation (NAPI) and kernel to kernel
        backpressure mechanism.

UDP guarantees:
        Packets will never be reordered or dropped before entering the
        kernel networking stack. However, sending bursts of UDP
        packets will get them dropped by the kernel because user space
        cannot read them fast enough. As always: Do not use raw UDP for
        sending bulk data. 

Implementation details:
        There are three hardware resources that this driver uses to
        implemented the communication:
        1. Cross CPU interrupt:
                When sending a packet an interrupt on the receiving CPU
                is triggered by the sender to inform it about the
                available packet. This avoids costly polling and
                improves latency.
        2. SRAM mailbox:
                We have 1024K fast SRAM memory accessible by both CPUs
                where we place ring buffers (fifo/queue). These queues
                are used for signalling (how many packets are available)
                and to deliver length information about the available
                packets. The elements of the queue are just 32bit
                integers (the length of the packet).
        3. DRAM mempool:
                The slower DRAM is used do deliver the payloads of the
                packets. Each SRAM queue offset correlates to one MTU
                sized buffer in DRAM. When reading one element from SRAM
                the receiver implicitly knows the address of the payload
                and can read it from there.

Security:
        Our assumption is that we cannot trust the other CPU as it might
        be compromised. Therefore anything received must be checked for
        sanity. Strictly speaking it is only the bootcore that views the
        interaptiv as compromised but it is not necessary to make
        this distinction for the following discussion. There are two
        ways by which we can receive data from a compromised CPU: SRAM
        mailbox or DRAM mempool. We discuss both in the following:
        1. SRAM mailbox:
                This is the most critical part as the whole mailbox is
                read and writeable by both CPUs at any time. To make it
                worse the read and write pointers of the queues inside the
                SRAM are used to calculate offsets and could therefore
                be used to access random memory when not properly bound
                checked. We argue that our code is secure because we bound
                check read and write pointers on every access against a
                maximum capacity known at compile time. The contents of
                the queue are the sizes of the packets. These are checked
                against the DRAM buffer size (MTU) known at compile
                time.
        2. DRAM memory:
                The mempools only contain fixed size buffers with
                compile time known offsets that are derived from the
                bound checked SRAM queue offsets. When a packet is
                received the payload is copied to private memory not
                accessible by the other CPU. Therefore there is no way for the
                sender to tamper with the packet contents as soon as the
                receiver passed it to the networking stack. The validity of
                the payload itself is not subject to driver checks
                but is checked by the networking stack and hopefuly by the
                users of the device (you).

Multi-EVA boot on MIPS: (Seale, Falcon)

GPL-Browser

Daily updated index of all cpunet.ko code findings on the GPL-Browser. Last update: 2024-09-21 04:05 GMT.
The Files header attempts to list the files which belong to this module. Useful if a directory contains multiple modules.
The Browse column points to the Path of the Makefile referring this code on the gpl.boxmatrix.info service.
The SoC column lists the Chip-Codenames, the Model column lists the nicks of the Box-Models.
The Diff column links the comparison of the AVM Kernel to the pristine original from Kernel.org.
The Download column links the full tarball the respective directory content is extracted from.
The presence of the source does not mean it fits the respective model and architecture. See the Model-Matrix where it's used.
Note that this list matches module names with hyphen (-) and underscore (_) exchangeable, same as modprobe does.

Dependencies

Daily updated index of all dependencies of this module. Last update: 2024-09-20 07:27 GMT.
A * in the Mod column marks info from Supportdata-Probes, which will always stay incomplete.

Relation Typ Object Mod Firmware Info Origin
0 dependencies for this module

Model-Matrix

Daily updated index of the presence, path and size of this module for each model. Last update: 2024-09-21 04:50 GMT.
Showing all models using this module. Click any column header (click-wait-click) to sort the list by the respective data.
The (main/scrpn/boot/arm/prx/atom) label in the Model column shows which CPU is meant for models with multiple Linux instances.
Note that this list is merged from Firmware-Probes of all known AVM firmware for a model, including Recovery.exe and Labor-Files.

Model Firmware Path Size
FRITZ!Box 5530 Fiber (boot) 7.21 - 7.81 ./extra 15.2k - 15.3k
FRITZ!Box 5530 Fiber (main) 7.21 - 7.81 ./extra 17.0k - 17.7k
FRITZ!Box 5590 Fiber (arm) 7.27 - 7.90 ./extra 17.0k - 20.5k
FRITZ!Box 5590 Fiber (boot) 7.27 - 7.90 ./extra 15.2k - 18.1k
FRITZ!Box 5590 Fiber (prx) 7.27 - 7.90 ./extra 17.0k - 20.5k
FRITZ!Box 6850 LTE 7.26 - 7.39 ./extra 17.3k - 17.6k
FRITZ!Box 6890 LTE 7.21 - 7.57 ./extra 17.3k - 20.8k
FRITZ!Box 6890 LTE v1 7.21 - 7.57 ./extra 17.3k - 20.8k
FRITZ!Box 6890 LTE v2 7.21 - 7.57 ./extra 17.3k - 20.8k
FRITZ!Box 7560 7.24 - 7.30 ./extra 17.3k
FRITZ!Box 7580 7.21 - 7.30 ./extra 17.3k
FRITZ!Box 7583 7.21 - 7.59 ./extra 17.3k - 20.8k
FRITZ!Box 7583 VDSL 7.19 - 7.59 ./extra 17.3k - 20.8k
FRITZ!Box 7590 7.19 - 7.90 ./extra, /usr/lib/debug/lib/modules/4.9.325/extra 17.3k - 420k
FRITZ!Box 7590 AX 7.19 - 7.90 ./extra, /usr/lib/debug/lib/modules/4.9.325/extra 17.3k - 420k
15 models use this module

Symbols

Daily updated index of all symbols of this module. Last update: 2024-09-20 07:27 GMT.

Firmware Symbol
7.19 - 7.90 cleanup_module
7.19 - 7.90 cpunet_driver_exit
7.19 - 7.90 cpunet_driver_init
7.19 - 7.90 cpunet_hw_ack_int
7.19 - 7.90 cpunet_hw_buffer_size
7.19 - 7.90 cpunet_hw_disable_int
7.19 - 7.90 cpunet_hw_enable_int
7.19 - 7.90 cpunet_hw_exit
7.19 - 7.90 cpunet_hw_init
7.19 - 7.90 cpunet_hw_max_num
7.19 - 7.90 cpunet_hw_rx
7.19 - 7.90 cpunet_hw_rx_done
7.19 - 7.90 cpunet_hw_tx
7.19 - 7.90 cpunet_hw_tx_alloc
7.19 - 7.90 cpunet_hw_tx_full
7.19 - 7.90 cpunet_isr
7.19 - 7.90 cpunet_poll
7.19 - 7.90 cpunet_probe
7.19 - 7.90 cpunet_remove
7.19 - 7.90 cpunet_setup
7.19 - 7.90 cpunet_xmit
7.19 - 7.90 create_dma
7.21 - 7.30 exit_mailbox
7.19 - 7.90 exit_mailbox.isra.2
7.21 - 7.90 exit_mailbox.isra.5
7.19 - 7.90 exit_mempool
7.19 - 7.90 get_memory
7.19 - 7.90 get_phandle
7.19 - 7.90 init_module
7.21 - 7.30 queue_is_full
7.19 - 7.90 queue_is_full.isra.3
7.19 - 7.90 remove_device
7.19 - 7.90 remove_dma
7.19 - 7.90 timer_retry_rx
34 symbols for this module

SMW-Browser

Information is currently being retrieved from the backend.
 

Synonyms

Showing 1 related property.

c