c0rnelius

If you have never built an image, I don't recommend getting your feet wet trying on a tv box. I bricked one of my boxes a couple times before getting this u-boot right, so unless you know how to unbrick it, it is not something you should be playing with. I posted the patches for those who may be interested in adding the support.

I use mainline u-boot on my X96-AIR GBIT. It being a TVBOX, I'm not gonna help people brick their unit, but for those in the know and or willing to try, these are the bits I use. Firmware Image Package can be found here: https://github.com/pyavitz/debian-image-builder/releases/download/amlogic-boot-fip/amlogic-boot-fip-master.tar.gz I also have a kernel patch set. Although its modded for use with the jl2xx1 ETH module. NOTE: The u-boot patches should work with v2023.01 / 04. The vendor 'ANDROID' u-boot needs to be purged from the eMMC: dd if=/dev/zero of="/dev/${node}" bs=32768 count=32768 https://paste.debian.net/1277482/ 001-u-boot-v2023.04-x96-air-gbit-support.patch 002-meson64-boot-target-usb.patch

Absolutely. This has nothing to do with bluetooth. It's related to wifi and the error can be seen on all modern linux kernels. Creating a symlink will make it go away. With that said, the error doesn't break anything and it's just telling you the file is missing.

Although it was initially for use on Raspbian it works on Debian, Devuan and Ubuntu all the same. So it should work fine on Armbian. There is also Bluez hack that the Foundation and Ubuntu use to make sure the firmware is found and loaded during boot, but this can be avoided by simply creating a symlink `ln -s /lib/firmware /etc/firmware`.

Is the pi-bluetooth package installed? The package its self is just a set of scripts, rules and services: https://github.com/RPi-Distro/pi-bluetooth https://packages.ubuntu.com/jammy/pi-bluetooth Interestingly enough, this isn't required when using a mainline kernel. But that's a topic for another day.

HDMI sudo amixer -c 0 set 'TOHDMITX' 'on' sudo amixer -c 0 set 'TOHDMITX I2S SRC' 'I2S B' sudo amixer -c 0 set 'TDMOUT_B SRC SEL' 'IN 0' sudo amixer -c 0 set 'FRDDR_A SRC 2 EN' 'on' sudo amixer -c 0 set 'FRDDR_A SINK 1 SEL' 'OUT 0' sudo amixer -c 0 set 'FRDDR_A SINK 2 SEL' 'OUT 1' sudo amixer -c 0 set 'FRDDR_A SINK 3 SEL' 'OUT 2' sudo amixer -c 0 set 'ACODEC' '85%' # not needed for the C4 sudo alsactl store ANALOG sudo amixer -c 0 set 'TOACODEC OUT EN' 'on' sudo amixer -c 0 set 'TOACODEC SRC' 'I2S B' sudo amixer -c 0 set 'TDMOUT_B SRC SEL' 'IN 0' sudo amixer -c 0 set 'FRDDR_A SRC 2 EN' 'on' sudo amixer -c 0 set 'FRDDR_A SINK 1 SEL' 'OUT 0' sudo amixer -c 0 set 'FRDDR_A SINK 2 SEL' 'OUT 1' sudo amixer -c 0 set 'FRDDR_A SINK 3 SEL' 'OUT 2' sudo amixer -c 0 set 'ACODEC' '85%' sudo alsactl store

Can you up ur build to v2022.07? It's actually missing from the defconfig in that revision. I needed to manually add it to get vid output.

I'm fairly certain removing this `CONFIG_DM_RESET=y` from the uboot defconfig will stop video output on the tinker during initial boot. https://lore.kernel.org/u-boot/20230106165229.GZ3787616@bill-the-cat/

I've been using: https://github.com/jethome-ru/rtl88x2cs.git

More than likely the /boot is a vfat partition and as it suggests creating a hard link isn't supported. The initrd is still getting updated.

This happens on both the Rock64 and Renegade and I would think other boards using the RK3328 SoC.. The fix is to patch, compile and in this case, re-flash u-boot. The attachment patch has been tested on U-Boot v2022.07/10 HDMI output appears to be broken on 6.1.y "in my experience". So if Manjaro has moved to that kernel, that would explain why HDMI is no longer working. 003-rk3328-set-VOP-QoS-to-high-priority.patch

The boot partition is flagged ESP, which the PI3 does not support. Model: Generic MassStorageClass (scsi) Disk /dev/sdd: 32.0GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 4194kB 273MB 268MB primary fat32 esp 2 273MB 4106MB 3834MB primary ext4 Removing the ESP flag from the boot partition should allow the image to boot on both the RPi3 and RPi4. This can be easily done using gparted. if you are comfortable using the command line: sudo parted /dev/XXX set 1 esp off

sudo wget https://raw.githubusercontent.com/canonical/cloud-utils/main/bin/growpart -P /usr/local/bin/ sudo chmod +x /usr/local/bin/growpart # assuming we are resizing an ext4 partition "/dev/mmcblk1p1": sudo growpart /dev/mmcblk1 1 sudo resize2fs /dev/mmcblk1p1

My efforts into this are done. I was asked to make it boot and get it functioning, not to produce images for the masses. I think as that goes, I did as much. Sorry the kernel doesn't have everything "that everyone ever wanted" ticked on, but that wasn't a concern of mine at the time. With that said, I added support for it in the defconfig, if you or someone else wants to compile their own kernel for those images, you are more than welcome too. Honestly, I would suggest people check the commit: https://github.com/armbian/build/pull/4247 and help provide proper Armbian support. Thanx

Someone went through the trouble to update and re-submit; https://lore.kernel.org/linux-rockchip/20220930051246.391614-1-aurelien@aurel32.net/T/#t If to lazy, you can pull it from here; https://github.com/pyavitz/debian-image-builder/tree/feature/patches/rockchip/rk356x/odroidm1/5.19 Last I heard everything worked but the eMMC, but that was "fixed" in V3. So hopefully that's fine now.

A 'common' way with the current setup would be to load the overlay using extlinux. example: /boot/extlinux/extlinux.conf fdtoverlays ../rockchip/overlays/rockchip-rk3399-opp-2ghz.dtbo I don't know if its currently supported and if it is and you created the overlay, that's how you would load it at boot.

What rkbins are you using? I've been using RKBIN_ELF="rkbin-master/bin/rk35/rk3568_bl31_v1.24.elf" RKBIN_RAM="rkbin-master/bin/rk35/rk3568_ddr_1560MHz_v1.13.bin"

9bx154, open an issue or create a PR with what you want ticked on. --> https://github.com/pyavitz/debian-image-builder defconfig -> rockchip64-rk356x_defconfig

9bx154, its uploaded. #4

I'll add it to the build and see what people report. Thanx.

Vendor u-boot needs to be purged from the eMMC: https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R5S#The_Boot_order_between_eMMC_and_SD_card I drop test imgs and kernels here: https://github.com/pyavitz/binary/releases/tag/images What was last reported; 5.19.3-2022-08-22 boots but no m.2, nor proper eth led functions. 5.19.6 I was told it booted, but then upon powering down the device it wouldn't come back. No other info given. Only change between 5.19.3 and 5.19.6 was a defconfig adjustment. Not tested; 5.19.8-2022-09-10 pin-ctrl added in hopes it brings up the m.2 and a custom led patch for the eth ports. Can open an issue there or find me on IRC / Discord.

I think I can help here as I'm already working on this off and on. The problem I have is I don't own the hardware, so I'm not going to be submitting any thing to Armbian. But so far "as I'm told by the tester" I have the board booting and everything working except the m.2 and eth leds. Those two bits are a WIP and I'm currently waiting for the tester to get back from holiday so he can see if its working now. As for submitting the work to Armbian. I'd be happy to point whom ever to what I've done so far and help where I can.

If you open the dts file for said board, you'll see something like this a few lines down from the top -> model = "Hardkernel ODROID-C4"; Whatever you put in there is what will spit out the model. You can name it -> model = "Hookers and Flapjacks"; Although, beyond laughs I see no real point in changing this.