c0rnelius
-
Posts
116 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by 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.
Quotebrcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin failed with error -2
It's related to wifi and the error can be seen on all modern linux kernels. Creating a symlink will make it go away.
Quoteln -s brcmfmac43455-sdio.bin brcmfmac43455-sdio.raspberrypi,4-model-b.bin
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 storeANALOG
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/
-
-
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.
-
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 ext4Removing 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.dtboI 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.
-
I've also noticed using an overlay to overclock the RK3399 on 5.15.y doesn't work, although in my testing it does work fine on 5.17 / 5.18.y. One solution is to patch the rk3399-opp.dtsi and add a turbo-mode switch. This way the board can be overclocked on the fly with a simple `echo "1" > sudo tee /sys/devices/system/cpu/cpufreq/boost`.
Create BTRFS subvolumes by default
in Framework and userspace feature requests
Posted
This is a pretty easy add. Basically after creating the btrfs filesystem, mount the LOOP and create the subvolume, now unmount the LOOP and remount it with the correct flags.
Lets pretend these are the variables.
P_ROOTFS="/mnt/p1"
IMAGE_LOOP_DEV_ROOTFS="/dev/loop1p1"
mkfs.btrfs -f -L ROOTFS ${IMAGE_LOOP_DEV_ROOTFS} mount "${IMAGE_LOOP_DEV_ROOTFS}" ${P_ROOTFS} btrfs subvolume create ${P_ROOTFS}/@ umount ${P_ROOTFS} mount -o compress=lzo,noatime,subvol=@ ${IMAGE_LOOP_DEV_ROOTFS} ${P_ROOTFS}Where all this would reside in the Armbian framework, I'm not really sure? But in general it wouldn't take that much effort to introduce. One issue I can see popping up, is that U-Boot "last I checked?" doesn't support BTRFS subvolumes. So if subvolumes were an option, the image would require a VFAT or EXT4 BOOT partition.