If you even want to upstream it then DTS hardcoding wont fly, at least not hardcoding the raw register value.
Think the best way to upstream this is add an entry like
mac0_1.8
mac56_1.8
and set the regs in the driver based on this settings...
So in our case... the current dsa driver have the mac0 set to the wrong value
Ok, there's a small problem, but it's not directly related to your build. There's no way to configure VLAN options in luci with DSA it seems. The PR that's supposed to add this has been sitting idle for some time now: https://github.com/openwrt/luci/pull/4307
Hopefully it will be merged soon.
1 Like
Yes also the current dsa driver doesn't support hardware vlan. (Added in kernel 5.8) This is just to test if dsa is stable (with all the other things)
Anyway in theory only Luci support is absent... The network config should be already supported. (But I had some problem adding support for it)
So software VLAN works on DSA with the current kernel? In that case, do you know of a good guide on how to configure it? I think just testing your build on my AP R7800 is not enough. Running it on my main R7800 would be a better "stress test", if you can call it that.
I know you're busy with a lot of stuff, but are you still working on kernel 5.10?
the reason i'm fixing all this issue is for kernel 5.10... the best thing would be 5.10 and switch ipq806x to dsa
with the port of 5.10 i discovered the problem of the regulator never working.
Yes software vlan works on dsa... Problem is the lack of documentation of the the new vlan system for dsa... in the pull request you posted there are some configuration example that should work.
I can try do some test about vlan if you want
1 Like
The pending luci pull request for dsa works quite nicely for me (gs1900-8/ realtek) - at least for the simple needs.
can you post a simple setup ? network config example
I can't get to it right now, but will have a look when I get home in the evening.
2 Likes
Do we have some user with a ipq8064 router? I pushed the patch that should add support for ar8327 switch... need someone that can test them.
@robimarko if you want to check the patches. Added the mac_pwr_sel function
I have an Asrock G10, it's based on 8064.
I can test some stuff, but not before Thursday.
I took a quick peek at the patch, you also need to add the AR8327 PHY ID so they will get registered through the internal bus, otherwise, it won't work.
i searched where the phy id is used but i can't find where that define is used... any hint?
It looks like the mdio phy id check in qca8k is absent... Should i add it ?
It actually looks like its defined in the qca8k.h and then newer used.
So it looks like its not important
i checked the original code from qsdk and the phy_id another check just like the switch id.
I would include the phy_id just in case but i think we can skip the code
pushed some commit with the conversion of asrock g10 to dsa
Anyway as a side project... i also fixed the nand driver... no more I/O error
@robimarko @hnyman
Created a patch...
The long story...
the ipq806x nand original driver expose a sysfs flag that set the boot_layout flag
This flag sets some custom ecc and write data to the driver.
From the qsdk this flag is set when these partition needs to be write/read
This is the qsdk platform code
case "${sec}" in
hlos*) switch_layout linux; image_is_nand && return || do_flash_failsafe_partition ${sec} "0:HLOS";;
rootfs*) switch_layout linux; image_is_nand && return || do_flash_failsafe_partition ${sec} "rootfs";;
wififw-*) switch_layout linux; do_flash_failsafe_partition ${sec} "0:WIFIFW";;
wififw_ubi-*) switch_layout linux; do_flash_ubi ${sec} "0:WIFIFW";;
wififw_v${version}-*) switch_layout linux; do_flash_failsafe_partition ${sec} "0:WIFIFW";;
wififw_ubi_v${version}-*) switch_layout linux; do_flash_ubi ${sec} "0:WIFIFW";;
fs*) switch_layout linux; do_flash_failsafe_partition ${sec} "rootfs";;
ubi*) switch_layout linux; image_is_nand || return && do_flash_ubi ${sec} "rootfs";;
sbl1*) switch_layout boot; do_flash_partition ${sec} "0:SBL1";;
sbl2*) switch_layout boot; do_flash_failsafe_partition ${sec} "0:SBL2";;
sbl3*) switch_layout boot; do_flash_failsafe_partition ${sec} "0:SBL3";;
dtb-$(to_upper $board)*) switch_layout boot; do_flash_partition ${sec} "0:DTB";;
u-boot*) switch_layout boot; do_flash_failsafe_partition ${sec} "0:APPSBL";;
lkboot*) switch_layout boot; do_flash_failsafe_partition ${sec} "0:APPSBL";;
ddr-$(to_upper $board)*) switch_layout boot; do_flash_ddr ${sec};;
ddr-${board}-*) switch_layout boot; do_flash_failsafe_partition ${sec} "0:DDRCONFIG";;
ssd*) switch_layout boot; do_flash_partition ${sec} "0:SSD";;
tz*) switch_layout boot; do_flash_tz ${sec};;
apdp*) switch_layout boot; do_flash_failsafe_partition ${sec} "0:APDP";;
devcfg*) switch_layout boot; do_flash_failsafe_partition ${sec} "0:DEVCFG";;
rpm*) switch_layout boot; do_flash_failsafe_partition ${sec} "0:RPM";;
*) echo "Section ${sec} ignored"; return 1;;
esac
switch_layout boot sets the flag to use the boot configuration
switch_layout linux sets the flag to use the normal configuration
This direct set is problematic since normally the block driver read these partition and prints error as they are read with the wrong configuration.
I made an assumption: since the boot partition should be always at the start of the nand, we can set the driver to treat the read/write operation based on the page that is asked to do (in the code there is a conversion that convert the size in hex to pages, every page is 2kb)
This way we can drop the boot_layout sysfs flag and the driver decide what configuration to use...
Now the 2 problem are:
- Is my assumption correct? or in your opinion there can be some partition not at the start of the nand that requires this special mode?
- We don't really know where the boot_layout ends... It's all set by the oem... Also here we can assume that the boot_layout ends right before the APPSBLENV
Since this is the mtd driver... I would ask you if the fact that the block driver doesn't print any error is the correct way to tell that this bug is fixed... (again the real problem is understand the parittions thet requires this special mode)
(i pushed the related patch to the repo)
2 Likes
I was not aware of this issue at all,
and honestly, I have no experience with MTD outside of some SPI-NOR and SPI-NAND support.
Mhh It doesn't specify the type am I wrong?
Anyway looks to be a bool. We actually need to specify the size of the boot partitions where the special ECC configuration should be used
Yes, exactly. It's a partition flag.
Ah, no. Sorry, I take that back. I first thought it is but it is a chip option, so yes, it does not handle the size per se so that we would still need to do in a controller driver specific way.