Radxa Rock 4D and "Waveshare PCIe to 2-CH SATA HAT+" (Pcie/SATA overaly missing)

[cest73]

Armbianmonitor:

https://paste.armbian.com/bayoyehune

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.

 

[cest73]

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?

[cest73]

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?
 

[cest73]

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?
 

[cest73]

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����������������������������