What my guess is, that the AQR firmware is loaded onto the RTL9301 bus via the SPI control interface.
I personally would start the other way around; load the vendor firmware, and try to talk via spi first. That'll let you ensure your binary works; then, swap it around
Ok, understood. Is the speed wrong? Any other suspects?
Update
trying go back to basics: in order to read register over spi i need to set MSB to 1 and I need to send 2 more dummy bytes to read data back . so for reading rtl9301 16-bit registers 'p' parameter for spidev_test would be 'x80x04x00x00'.
tried this with different speeds/modes/word sizes - getting only 0s back. on oem firmware too
I noticed that when I change bridge config on OEM GUI, it will push changes through /tmp/rtl9303_diag.fifo.
root@CR1000A:/rom/usr/bin# tail -f /tmp/rtl9303_diag.fifo
port set port 8 state disable
port set port 20 state disable
port set port 24 state disable
which similar to the init.d: cat /etc/init.d/rtl-9303: (This could be a way to push config to switch when you figure out how to run usrApp)
boot() {
mkfifo $DIAG_FIFO
tail -f $DIAG_FIFO | /usr/bin/usrApp&
sleep 2
echo "port set port all state disable" > $DIAG_FIFO
# Clean up vlan table and l2 table for caching
# echo "vlan destroy all restore-default-vlan" > $DIAG_FIFO
Afaik you need 16 bits for the address, but I'd bet/expect 16 additional bits are needed to make it a full 32 bits. The returned data will be 32bits for sure.
Being able to use the vendor binary on openwrt would also be useful, as you can then just print out a copy (by hacking the spi-dev driver) of whatever the vendor app is doing. Both options are fair, but both rely on a properly setup dts with properly setup spi busses. Did you try using the vendor DTS with openwrT? half the stuff won't work; but the SPI stuff should be fine?
Btw, I take it that /tmp/rtl9303_diag.fifo is created by the realtek app to create an interface to the rest of the OS?
what you can also try first, before going down the GDB route;
write a little application, that creates a filedescriptor and listens on it (file-pipe?) idk. then, use that as output to the userApp. e.g. userapp -> /dev/myapp and printf anything that userapp sends.
To make it extra special, send whatever userapp inputs, also to the real spi device (and everything you read, back to the file-pipe)
Basically, doing a 'man-in-the-middle' thing. That way, you can see exactly what they are sending/receiving.
it helps - it at least shows that SPI is used. But I can't make SPI work; and from available realtek SDK sources the ioal_init() which fails is just a wrapper around drv_swcore_ioalCB_register() which i have no sources for.
I have very little time as of recently to dedicate to this project, so here is the latest:
RTL9301 doesn't work (this affects all lan side: 2x2.5G + 1x10G + 1MoCA)
everything else works (3x wifi, usb, wan 10G, serial, etc)
Which, by default, is not enabled on OpenWrt (or other mainstream general purpose distributions) for security reasons (but it can be for private testing and debugging).
It's a busybox applet - and busybox' configuration settings are guarded by the developer settings (as doing so holds a high risk of rendering the image unbootable or similar).
