The TVE200 DRM driver drives the display here; the legacy fbdev stack
only added the framebuffer console on top of it, through DRM fbdev
emulation. Drop it, with the fonts and the boot logo that depend on
fbdev core, and the virtual terminal layer that had nothing left to bind
to. kmscon in the video feed provides a terminal on the KMS device for
anyone who wants one back.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The fragment carries "# CONFIG_EXPERT is not set" while every other
target inherits CONFIG_EXPERT=y from target/linux/generic. That looks
like an artefact of an imported defconfig, and it has a consequence: a
symbol whose prompt is conditional on EXPERT stops being settable with
EXPERT off and silently takes its own default, so the generic fragment
cannot control it.
CONFIG_VT is one of those, declared bool "Virtual terminal" if EXPERT
with default y, which is why the "# CONFIG_VT is not set" in generic has
no effect on this target today. Drop the override so gemini resolves such
symbols the same way as everything else.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
gemini enables ext4 for the hard disk image of the D-Link DNS-313, so
the flash images of the DIR-685 are built for ext4 as well. The ext4
root file system is padded to CONFIG_TARGET_ROOTFS_PARTSIZE, which
makes these images about 108 MiB, while the DIR-685 has 32 MiB of
flash.
The ext4 sysupgrade image is broken anyway: the ext4 images are gzipped
as a whole, which moves the image metadata into the gzip stream, so
sysupgrade rejects it with "Image metadata not present".
Build the DIR-685 images for squashfs only, like the StorLink reference
designs.
Link: https://github.com/openwrt/openwrt/pull/25658
Signed-off-by: Paul Spooren <mail@aparcar.org>
The boot partition of the DNS-313 factory image differs between builds:
-Linux rev 1.0 ext2 filesystem data, UUID=9f7d7721-0bf7-4483-bd56-b539d195f181
+Linux rev 1.0 ext2 filesystem data, UUID=d3ca4870-378b-48dd-9b05-760812dfeb81
-drwxr-xr-x ... 2026-09-23 07:37:23.000000 ./.boot/
+drwxr-xr-x ... 2026-09-23 09:38:09.000000 ./.boot/
genext2fs copies the mtimes of the staged files from the host and adds
them in readdir() order, which also decides their inode numbers and
blocks. It leaves the UUID empty, so e2fsck fills in a random one, and
e2fsck stamps the last check with the current time.
Pass genext2fs a name sorted tarball with mtimes clamped to
SOURCE_DATE_EPOCH and group/other write bits cleared, derive the UUID
from IMG_PART_DISKGUID and run e2fsck with E2FSCK_TIME set to
SOURCE_DATE_EPOCH.
Link: https://github.com/openwrt/openwrt/pull/25358
Signed-off-by: Paul Spooren <mail@aparcar.org>
Both features describe an SoC family, which is the wrong granularity: a
mediatek/mt7623 board claims a display while a filogic board with a MIPI
DBI panel cannot, and rockchip claims audio for a NanoPi R2S as much as
for a Rock 5B. The audio-support and video-support packages carry that
information per image, and the modules depend on them.
Drop both features from every target that declares them.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The display target feature gates every DRM module, but it says nothing
useful: it is set on ten targets, so a mediatek/mt7623 board can have a
display while a filogic board with a MIPI DBI panel cannot, and rockchip
claims it for a NanoPi R2S as much as for a Rock 5B. Whether a board
drives a panel is a per-device choice, not a property of the SoC family.
The DRM and V4L2 nodes also end up 0600 root:root, so a display server
runs as root or not at all.
Add a video-support package which allocates the video and video-capture
groups and installs the hotplug rules for the DRM and V4L2 nodes, and
make the modules depend on it. The dependency is a plain one, not a
select, so the modules are offered once the feature is chosen. Targets
whose display drivers are built into the kernel carry the package in
DEFAULT_PACKAGES, since no module pulls it in for them, and the one
device profile that ships a DRM module on another target lists it
directly. DISPLAY_SUPPORT stays for now, so this changes no existing
selection.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The FOTG210 USB host controller is not working on Gemini with 6.18.
Backport the migration to the common EHCI core and other fixups
just merged for 7.4.
Link: https://github.com/openwrt/openwrt/pull/25139
Signed-off-by: Linus Walleij <linusw@kernel.org>
Add support for Teltonika RUT104 3G HSUPA router.
This has been supported since about 20 years in the upstream Linux
kernel after initial contribution by Paulius Zaleckas from Teltonika.
It has some historical significance because I think it was one of the
first Teltonika Linux-based 3G routers.
Installation from scratch is done using the UART:
- UART soldering instructions with picture are available on the
Link: (see bottom of committ message).
- First *diet down* your OpenWrt build as minimal as you can,
I really mean this, delete everything you don't need. There
is not much RAM to go around.
- Extract the "factory" firmare which is essentially just a tar.gz
archive:
tar xvfz openwrt-gemini-generic-teltonika_rut104-squashfs-factory.bin
From the RedBoot menu:
- Do NOT UNDER ANY CIRCUMSTANCE try to use the "upgrade firmare" (Z)
alternative!
- Extract the three files zImage, rd.gz and hddapp.tgz from the archive.
- Put these three files in the root directory of your TFTP server
(usually /var/lib/tftpboot)
- Hit 6 and set up the IP address for your device (e.g. 169.254.1.2 if
you're using local link).
- Hit Y to "Upgrade Kernel", enter TFTP and your hosts IP number and
type zImage. The kernel should upload and flash.
- Hit R to "Upgrade Ramdisk", enter TFTP and your hosts IP number and
type rd.gz. The "ramdisk" (i.e. the second part of the kernel)
should upload and flash.
- Hit A to "Upgrade Application", enter TFTP and your hosts IP number
and type hddapp.tgz. The "application" (i.e. the root filesystem)
should upload and flash.
This has a 1024KB Kernel partition, just extend the existing Make
functions to handle also this. The initramfs is 0x500000 instead
of 0x600000 for this one so add a parameter explicitly parameterizing
the initramfs size.
Mark non-default due to the small RAM and flash on this device.
I currently have no idea how to actually talk to the modem on this
thing but it is probably using the high-speed "modem UART" of the
Gemini. I'd be willing to help whoever wants to experiment with
it.
Link: https://dflund.se/~triad/krad/teltonika/
Link: https://github.com/openwrt/openwrt/pull/22045
Signed-off-by: Linus Walleij <linusw@kernel.org>
There has been some modified device trees floating on forums to
make this device work, collect the work and integrate it into
OpenWrt so it hopefully works for users.
Link: https://github.com/openwrt/openwrt/pull/21998
Signed-off-by: Linus Walleij <linusw@kernel.org>
This is patch is identical in form and purpose as the IB-4220-B
patch. We switch over to a single "firmware" partition.
All reference design-based machines are now converted and we can
drop the legacy set-up code.
It turns out that the reference design also uses the flash layout
with a 3072KB kernel so augment the sysupgrade to do the right
thing also here.
Link: https://github.com/openwrt/openwrt/pull/21820
Signed-off-by: Linus Walleij <linusw@kernel.org>
To optimize the flash usage and to make firmware upgrades
simpler, catenate the three firmware partitions "Kern",
"Ramdisk" and "Application" into one, and use all of this
for the combined MTD-splitted kernel+rootfs.
This works fine as long as the kernel is placed in the
beginning of this firmware partition and we leave the
RedBoot partition as is, so the boot loader still can load
the kernel from the first two RedBoot partitions.
Using the RedBoot partitions "as is" can be considered
harmful, because when you flash to a RedBoot partition the
file size is used for downsizing of the partition and make
firmware upgrades fail if they are larger than the RedBoot
partition size after flashing, despite there is actually
flash there. So overriding with fixed partitions is just
generally a good idea.
Link: https://github.com/openwrt/openwrt/pull/21820
Signed-off-by: Linus Walleij <linusw@kernel.org>
The firmware update file can get big, so instead of extracting
the whole file into the tmp folder potentially running out of space
and make the upgrade fail, stream from tar xvf -O directly to the
mtd write command.
Refactor the checking of partitions and the actual upgrade into
two steps when we are at it.
Link: https://github.com/openwrt/openwrt/pull/21782
Signed-off-by: Linus Walleij <linusw@kernel.org>
The redboot partition parser gets upset if a partition
doesn't end on an even erase block and marks the partition
read-only.
Fix this by always padding the three firmware items to
128kb.
It is no longer required for the filesystem to be padded
to 6144kb, so we pad this to just 128kb like the kernel
images.
Link: https://github.com/openwrt/openwrt/pull/21750
Signed-off-by: Linus Walleij <linusw@kernel.org>
The Storlink reference designs sometimes fail upgrade because
not the entire partition is used, so the size isn't equal to
the actual flash space available for the partition.
Fix this by calculating the actual partition sizes by measuring
across the partition offsets instead.
Link: https://github.com/openwrt/openwrt/pull/21750
Signed-off-by: Linus Walleij <linusw@kernel.org>
The gemini is using split squashfs/jffs2 root filesystems on
all devices, so without CONFIG_BLK_DEV_LOOP the device does
not gain a writeable root filesystem with these boot messages:
mount_root: unable to create loop device
mount_root: jffs2 not ready yet, using temporary tmpfs overlay
and then it never gets out of that. Fix this so we get writeable
rootfs again.
Link: https://github.com/openwrt/openwrt/pull/21748
Signed-off-by: Linus Walleij <linusw@kernel.org>
The Raidsonic devices do not use a 2048k kernel "Kern"
partition like the Storlink reference designs. Instead
it uses a 3072k partition to fit a slightly
larger kernel.
Sadly the current OpenWrt Gemini kernel is still bigger
than 3072k so we need to make use of the Ramdisk
partition as well.
Create a special "copy-kernel" version that can deal
with the Raidsonic 3072k kernels. Tested on the
Raidsonic IB-4220-B booting kernel v6.12.66.
Fix a copy/paste error in the image generation makefile
while we are at it.
Link: https://github.com/openwrt/openwrt/pull/21686
Signed-off-by: Linus Walleij <linusw@kernel.org>
Gemini currently uses the PREEMPT model, which is not aligned with
OpenWrt's default. Switch to PREEMPT_NONE for consistency with OpenWrt's
default configuration. Preemption model selection is now available via
menuconfig for further customization.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
Link: https://github.com/openwrt/openwrt/pull/21413
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The Gemini reference design-derived devices uses a partition
format which is predictable and we can exploit this to offer
some proper upgrade path.
The kernel for these contains a hack to use this partition
format unaltered by combining the partitions "Kern" and "Ramdisk"
to one image with all of the kernel+ramdisk in memory.
Then the "Application" which is used for the rootfs go into its
own partition.
Standard flash layout:
Kern 2048k |
Ramdisk 6144k | = 9216k
Application 6144k | = 15360k
Following the pattern of the factory image we create three
images named zImage, rd.gz and hddapp.tgz (these filenames
are misleading! They are just required by the old firmware.)
and flash each individually with "mtd" during upgrades.
Since the IB-4220-V has a different layout with a bigger kernel
space we parameterize this so we can handle this too. (More
fixes are needed for that device though.)
A way to upgrade older OpenWrt on these platforms to the latest
and greatest will be to copy the file
target/linux/gemini/base-files/lib/upgrade/platform.sh
to /lib/upgrade/platform.sh
on your running system and then run sysupgrade from the image
produced after this patch.
The script is picky to sanity check the partitions before
commencing upgrade.
This was tested with a full sysupgrade on the iTian SQ201.
Link: https://github.com/openwrt/openwrt/pull/21680
Signed-off-by: Linus Walleij <linusw@kernel.org>
kmod-md-multipath was removed in kernel 6.12, remove the dependency here
too.
This fixes the build of the gemini target.
Fixes: d12a603de5 ("kernel: kmod-md-multipath: Depend on kernel 6.6")
Link: https://github.com/openwrt/openwrt/pull/19532
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Trying to use modules for the PHY:s does not work:
The ethernet driver does not like to probe if it can't find
the PHY.
The ethernet driver really likes to be compiled-in. It will
not probe otherwise. Some hardware issue.
Revert things to how they always worked until I maybe solve
this.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This reverts commit 1c993da8ff.
VSC kmod is broken and is causing all targets to fail compiling so revert.
Signed-off-by: Robert Marko <robimarko@gmail.com>
The CONFIG_NET_SWITCHDEV option is needed by CONFIG_DSA and some other
options. It is boolean, we have to compile it into the kernel it self.
Activate it for all targets in the generic configuration, it is already
activated for most of them. This allows to install DSA drivers as a
module.
On the ramips/mt7620 target the kernel would grown by 4.5kB.
For some small targets which do not support a DSA switch by default the
option is deactivated.
Link: https://github.com/openwrt/openwrt/pull/17668
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes the build of the gemini and the apm821xx target.
The e2fsck application returns an error code now and that makes the
build fail. The tune2fs command adds an extra option and the e2fsck
should later fix the file system. It is intentionally broken in this
place.
e2fsprogs was patched before to ignore this error.
Fixes: 95e4664b5e ("tools: e2fsprogs: drop e2fsck patch")
Link: https://github.com/openwrt/openwrt/pull/16607
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Use the absolute path to access the e2fsprogs applications. It is also
working with relative paths, but this makes sure that we use our
versions.
Link: https://github.com/openwrt/openwrt/pull/16607
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Daniel Golle
Paul Spooren
Linus Walleij
Shiji Yang
Thomas Richard
Stijn Tintel
Linus Walleij
Hauke Mehrtens
Robert Marko
Rosen Penev
John Audia
Leo Barsky