XpressReal(https://xpressreal.io/) is a family of Single Board Computers
developed in collaboration between Fyde Innovations, Radxa and Realtek.
XpressReal T3 is the first product in the family - a small form factor
high performance single board computer powered by the Realtek RTD1619B,
which runs FydeOS/openFyde and Linux!
Now we are adding the awesome Armbian Linux support for XpressReal T3!
This commit introduces some binary files that XpressReal T3 needed:
- firmware/realtek/rtd1619b
These binaries are the firmware for rtd1619b peripherals
(including the audio decoder, video decoder, etc.).
- u-boot-fw.tar.gz
This contains some co-processor firmware,
which needs to be loaded by u-boot in the early stage of boot.
- u-boot-prebuilt.tar.gz
These are hwsettings related files, used for tasks such as DDR initialization.
These files come from the rtd1619b SDK, which has already been open-sourced on our github:
- [firmware](https://github.com/XpressReal/linux-sdk/tree/main/meta-xpressreal/recipes-kernel/linux-firmware/files/rtd1619b)
- [u-boot prebuilts](https://github.com/XpressReal/linux-sdk/tree/main/meta-xpressreal/recipes-bsp/u-boot/files/prebuilt/rtd1619b)
* Drop CONFIG_CAN_TI_HECC module as it fails to compile
On other 32b configs
* Drop rk3588 collabora defconfig
* Drop CAN_TI_HECC from remaining as suggested by AI
when doing my initial changes [enabled a bunch of PHYs, made NFS/SMB
etc modules... random stuff], I somehow enabled some errata fixes, and
this one showed up in dmesg.
The real star of the show I'm pretty sure is CONFIG_PCS_MTK_USXGMII.
Note, it cannot be a module, but on this platform we probably wouldn't
want it to be anyway. When I say "it can't", I'm saying it breaks the
build during the linker phase for vmlinux. Probably worth fixing, but
I'm unclear where to start, other than it's probably a Kconfig
dependency problem.
CONFIG_I2C_SLAVE_EEPROM came along for the ride b/c it possibly made
sense with SFPs. But I haven't tried a test build without it yet.
For the record: this works with both my AQS-107-B0C2-CX [an 802.3bz
SFP+] and my FS.com SFP-10GSR-85 "generic" SFP+.
* Added a patch to add the lte_em05 driver
Adds support for the Quectel M2 WWAN card on the Rock 5T/5B+.
* Enable CONFIG_LTE and LTE_RM310 + LTE_EM05
Enables the lte_rm310 and lte_em05 drivers (drivers/net/lte/).
* Delete patch/kernel/rk35xx-vendor-6.1/net-lte-add-lte-em05-driver.patch
Changes in the patch submitted to armbian/linux-rockchip . Only config change needed now after that gets approved.
Also tick on:
CONFIG_SPI_LOOPBACK_TEST=m
CONFIG_SPI_SLAVE=y
CONFIG_SPI_SLAVE_TIME=m
CONFIG_SPI_SLAVE_SYSTEM_CONTROL=m
CONFIG_SPMI=y
CONFIG_SPMI_HISI3670=m
Signed-off-by: Patrick Yavitz <pyavitz@gmail.com>
- PocketBeagle 2 and BeaglePlay requires this driver.
- The M4 core supports ZephyrRTOS and FreeRTOS along with bare-metal.
- Is already enabled in current and edge branch
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
- Using RT kernel is a common thing on pocketbeagle 2. So add current-rt
branch similar to what is being done for the base k3 family.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
- PocketBeagle 2 and BeaglePlay requires this driver.
- The M4 core supports ZephyrRTOS and FreeRTOS along with bare-metal.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
