cest73

I'm back Asking for help on Radxa discord i got the answer to check for the FPC ("Flexible Printed Circuit") cable pin orientation and run lspci next. Turns out it was the cable all along, lspci returned: # lspci 00:00.0 PCI bridge: Rockchip Electronics Co., Ltd Device 3576 (rev 01) 01:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) and lsblk shows: # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 4.5T 0 disk └─sda1 8:1 0 4.5T 0 part sdb 8:16 0 223.6G 0 disk └─sdb1 8:17 0 223.6G 0 part mtdblock0 31:0 0 16M 0 disk mmcblk1 179:0 0 59.5G 0 disk ├─mmcblk1p1 179:1 0 16M 0 part /config ├─mmcblk1p2 179:2 0 300M 0 part /boot/efi └─mmcblk1p3 179:3 0 59.2G 0 part / zram0 253:0 0 1.9G 0 disk [SWAP] So now it works and i can carry on with making my NAS 😇

Hello NickA, fire-hound from discord here ... You do a tremendous service for us all, keep it up buddy! I loaded your recent build from here: https://github.com/NickAlilovic/build/releases and can confirm it works on my A7A. It correctly detected my Pimorony NVME Base lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mtdblock0 31:0 0 8M 0 disk mmcblk0 179:0 0 29.2G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot └─mmcblk0p2 179:2 0 28.6G 0 part /var/lib/containers/storage/overlay /var/log.hdd / zram0 254:0 0 3.9G 0 disk [SWAP] zram1 254:1 0 50M 0 disk /var/log zram2 254:2 0 0B 0 disk nvme0n1 259:0 0 238.5G 0 disk └─nvme0n1p1 259:1 0 238.5G 0 part /srv/dev-disk-by-uuid-b28b2f5c-ee2e-4ded-959e-22bc63051b1d and: screenfetch _,met$$$$$gg. root@radxa-cubie-a7a ,g$$$$$$$$$$$$$$$P. OS: Debian 13 trixie ,g$$P"" """Y$$.". Kernel: aarch64 Linux 6.6.98-vendor-sun60iw2 ,$$P' `$$$. Uptime: 11h 14m ',$$P ,ggs. `$$b: Packages: 661 `d$$' ,$P"' . $$$ Shell: bash 5.2.37 $$P d$' , $$P Disk: 4.9G / 271G (2%) $$: $$. - ,d$$' CPU: ARM Cortex-A55 Cortex-A76 @ 8x 1.794GHz $$\; Y$b._ _,d$P' RAM: 534MiB / 7928MiB Y$$. `.`"Y$$$$P"' `$$b "-.__ `Y$$ `Y$$. `$$b. `Y$$b. `"Y$b._ `"""" So far so good The issues: 1. The typical Armbian image has a module in the armbian-config and radxa's rsetup where one can set up the two leds conveiently to other than full on and heartbeat for the green and blue gpio leds respectively. I find it to be a nuisance to dig for that manually 2. The Ovralys module in armbian-config is returning an error - when entering DTO001 module (Device Tree Overlays) saying: Invalid overlay_prefix that might require deeper digging into the issue i guess? What works: Open Media Vault registers the NVME nicely as additional storage. I suspect booting off that NVME would work for an updated SPI bootloader i could test that if you want me to? If you need any other info or output I stand at Your disposal 😁

So far no dice with Armbian. I am trying my luck with the Radxa official image and will report how that goes eventually. Meanwhile feel free to offer ideas or procedures i could tackle

Well, i have unbound the a24 driver by now: echo -n "6-0050" > /sys/bus/i2c/drivers/at24/unbind apparently it was an Radxa specific eeprom he had hanged on to: # i2cget 6 0x50 0x00 i | xxd -r -p WARNING! This program can confuse your I2C bus, cause data loss and worse! I will read from device file /dev/i2c-6, chip address 0x50, data address 0x00, 32 bytes using read I2C block data. Continue? [Y/n] RADXX but the neighbor is a mistery: i2cget 6 0x51 0x00 i | xxd -r -p WARNING! This program can confuse your I2C bus, cause data loss and worse! I will read from device file /dev/i2c-6, chip address 0x51, data address 0x00, 32 bytes using read I2C block data. Continue? [Y/n] R-Po����������������������������

According to i2cdetect the "UU" means the eeprom is being accessed (used) by something, and indeed after checking dmesg i've found this: [ 8.135029] at24 6-0050: Looking up vcc-supply property in node /i2c@2ac90000/at24c16@50 failed The at24 is again a built in module and i am not sure how i can prevent it from accessing the 0x50 on i2c 6?

What do You know! # i2cdetect -l i2c-1 i2c rk3x-i2c I2C adapter i2c-2 i2c rk3x-i2c I2C adapter i2c-3 i2c rk3x-i2c I2C adapter i2c-6 i2c rk3x-i2c I2C adapter i2c-10 i2c ddc it was always there, just missed i2c -tools 😁 next: # i2cdetect -F 6 Functionalities implemented by /dev/i2c-6: I2C yes SMBus Quick Command yes SMBus Send Byte yes SMBus Receive Byte yes SMBus Write Byte yes SMBus Read Byte yes SMBus Write Word yes SMBus Read Word yes SMBus Process Call yes SMBus Block Write yes SMBus Block Read no SMBus Block Process Call no SMBus PEC yes I2C Block Write yes I2C Block Read yes SMBus Host Notify no 10-bit addressing no Target mode no And finally: # i2cdetect -y 6 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: UU UU UU UU UU UU UU UU -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- So we seem to have something there (at address 0x50). What would be the next steps? read out the eerpom? Also, why does the OS not take care of this automatically? How come Raspbian OS does?

I just tried to enable the i2c6 (/boot/dtb/rockchip/overlay/rk3576-i2c6-m0.dtbo) overlay by armbian-config but as i try to enter the overlay utility i get thrown out to the CLI with "Invalid overlay_prefix rk35xx" What gives?

Hi, the hardware in question: PCIe_TO_2-CH_SATA_HAT+ In expectation for the Rock 4D forum to arrive I am posting my issue here: The Rock 4D works and all is well The two SATA drives work over USB to SATA adapters - that is not ideal in the long term IMHO The HAT just arrived and i have no doubt in my mind that it can be defective in any way - i assume it is 100% operational. But when i connect it and plug the power in the Rock 4D boots, everything else works as usual, but the HAT just sits there without any signal. My questions: 1. How do i query the eeprom via the pins 27 & 28 (ID_SD & ID_SC), do i just enable the i2c_6 overlay? 2. What then? I queried the ahci module with: `modinfo ahci` but it is both a built in and i suspect it does not support my device anyway? Looking forward to try help get this nice board supported on Armbian for other FPC equipped devices.

Cheers, will do!

Hello to everyone. Being new around here I figured to drop one message here first... So, i have this Radxa Rock 4D SBC and i am quite impressed with it Me being me and SBC being what it is, yada... yada, i now have this hat+ from Waveshare - it is an dual SATA to PCIe adapter. It was designed for the Raspberry pi 5 obviously but Radxa has since started putting those FPC connectors on and i really would appreciate a 24/7 NAS with a SBC footprint... Long story short, it does not work out of the box - i have no doubt the product is okay it's just the HAT fails to initiate the OS and register. It reportedly has an eprom with data on it but my guess is it has to have a dtb overlay active and my rock 4D lacks anything in that regard (a "sata" in the overlay name) My issues? 1. Where is the Rock 4D forum or where do i post this issue best to?