Mhhh ok this should be the normal way to implement this... I'm still dubios about the use of pages instead of the size in hex
But will implement the nand-is-boot-medium way
1 Like
Perfect and thanks for all your hard work you put into this.
BTW: I recently got some ath11k M.2 E key cards. If you fancy playing around with those just PM me an address and I will ship you one as a present (;-p).
Hi,
I am dealing with AR8337 with completely different SoC: MT7620. The RGMII connection to the CPU looks fine, but just 3 out of 5 AR8337 Ethernet Intrfaces are working.
It is not clear to me if the AR 8337 is managed by the same driver located in:
/openwrt/target/linux/generic/files/drivers/net/phy
from every SoC.
Well, you got us there a tiny little bit off-topic. Anyway, you might have heard of them two flavours of switch drivers, good oldé swconfig stuff and them new dsa ones. But yeah, either variant will use the same driver across all SoC's as far as I can tell.
And yeah, the answer to your question (;-p). Yes, the one you are referring to would be the oldé swconfig one while the new dsa one is called qca8k and comes as part of the regular kernel (drivers/net/dsa/qca8k.c).
if you have the same ar8327 binding in the dts that directly set the regs, it's not that hard to add support for it... just take the switch documentation... convert the hex values to binary and check what is actually set... and compare what qca8k lacks
@sumo just to make sure... can you confirm that
no I/O error = correct values for the nand?
Also what about nand pages... they are always 2kb?
Anyway can confirm that the mdio driver is fixed... in 4 days no wan port crash...
1 Like
i take it this DSA config won't work with the NSS patches right?
sadly nope... someone should adapt the nss gmac driver to dsa
@sumo updated the nand commit... if you want to check it https://github.com/Ansuel/openwrt/commit/c0a59ba73ba93d69a03230868b335ddab7204f41
1 Like
Do you mean?
/openwrt/target/linux/generic/files/drivers/net/dsa/qca8k.c
I do not find it:
Sorry for the stupid question, but I am familiar with C/C++, but I am not with the configuration control of the open Source software.
the dsa driver is available upstream so you need to refer to the linux kernel source
(the target patches, modify the kernel code)
I will have a look at it tonight as I'm currently on them slopes skiing. Thanks!
1 Like
Now that i'm thinking about it... 18 more patches... that's a lot
Found something really strange...
The specific mdio reg 31 (reg_offset 31) requires some specific delay.
I notice this since still sometimes the mdio have some fail to detect the port (in the order of days)
So I investigate the regs and write operation with their return value...
I notice that right after any write to the reg_offset 31, the very next read produce garbage... (and unluckily the next read is every time the status of the port). The write to reg_offset 31 requires 16 more usec to the default delay of 8 (or 10... i still need to understand if it's safe to decrease the delay to 8)
Using the extra delay for reg 31 fix the problem...
To test all of this i simply repeated the read operation 5 times and check if every time the value was equal... And with my surprise, the value was correct and equal for every write/read except the one after the write of offset 31. (and after the normal init, offset 30 and 31 are the common one that are used)
From a very initial test (8 delay + extra for offset 31) it looks to work normally + i don't have random port dropping on the start
Anyway the major problem of the random port dropping (not considering the lost packet) is the fact that if for example one have a pppoe session and many service that are reloaded on wan reset (unbound, adblock, banip, hetunnel) the system overload and the wifi froze with lots of swba overrun error as the system can't handle the packet from the wifi... Sometimes this can even cause a crash of the wifi firmware and a simple downtime of 3-4 sec results in a downtime of 30-60 sec
2 Likes
Building from latest master breaks the R7800 for me, seems to crash or something.
Could be that I hit this... I must have pulled the src just before that commit.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=09fbc79bf6dc6365018944e1e0629b5f1c921790
hmm, I'm not sure if this is related but
an imagebuilder image for the r7500v2 for today had problems (reported here). In brief, the image won't build with the package block-mount and if i remove that, the resulting image boots but is essentially non functional. From the console, it looked like the device couldn't read its flash and all the prior configs/files weren't present.
Tftp flashing an image from late Jan. and restoring my configs got the device back.
1 Like
Hi,
I've played a little bit with samba4 configurations and recently while doing "fdisk -l" putty returned this:
I refreshed the firmware, but the backup GPT table is corrupt. How did it become corrupt, and how can I fix it? Does anyone knows?
And the partition 1 error is it normal?
Thanks in advance for any help on this.
Nevermind, fixed it with fdisk /dev/sda 
Im having trouble with samba4:
I followed this guide:
And it got me as far as I could. Can the problem be that Im using windows 8.1?
I also get this on explorer:
Can someone help please?
Is anyone able to enable EEE (Energy Efficient Ethernet)? The switch should support it, I set enable_eee to 1 in swconfig, but devices that connect to the port are unable to negotiate EEE.
ipq806x is about to move from swconfig to dsa switch drivers, see the kernel v5.10 PR and thread, it would probably be most useful if you could repeat your tests with dsa.
Edit: I would be rather surprised if anyone had tested EEE on QCA8337 (nor most other devices typically running OpenWrt), but the dsa drivers should offer you more insight with ethtool and iproute2 (EEE has been tested on the dsa based realtek target).