I am using version 23.05 + 5.15 kernel patch
Always, if a power failure occurs, set the clock resets to 2104-12-09
[ 1.510932] armada38x-rtc f2284000.rtc: registered as rtc0
[ 1.516453] armada38x-rtc f2284000.rtc: setting system clock to 2104-12-09T11:58:57 UTC (4258267137)
Is it normal ?
I don't think so. I'm on 23.05 as well, and this is what I have:
# dmesg |grep rtc
[ 1.485247] armada38x-rtc f2284000.rtc: registered as rtc0
[ 1.490784] armada38x-rtc f2284000.rtc: setting system clock to 2023-09-18T16:28:00 UTC (1695054480)
root@RB5009UG+S+IN:~# uptime
00:31:21 up 11 days, 5:59, load average: 0.00, 0.01, 0.00
root@MikroTik:~# date
Sat Sep 30 08:01:55 CEST 2023
root@MikroTik:~# dmesg |grep rtc
[ 1.510866] armada38x-rtc f2284000.rtc: registered as rtc0
[ 1.516386] armada38x-rtc f2284000.rtc: setting system clock to 2104-12-09T11:58:57 UTC (4258267137)
root@MikroTik:~# hwclock
Tue Dec 9 11:59:43 2104 0.000000 seconds
root@MikroTik:~# hwclock -w -l
root@MikroTik:~# hwclock
Sat Sep 30 08:02:27 2023 0.000000 seconds
....
root@MikroTik:~# hwclock -w -l
root@MikroTik:~# date
Sat Sep 30 08:08:47 CEST 2023
...
root@MikroTik:~# date
Sat Sep 30 08:10:24 CEST 2023
root@MikroTik:~# hwclock
Sat Sep 30 08:09:19 2023 0.000000 seconds
1 hour later
root@MikroTik:~# date
Sat Sep 30 09:10:31 CEST 2023
root@MikroTik:~t# hwclock
Sat Sep 30 06:59:49 2023 0.000000 seconds
Edit: It was already here
In the original dts decompiled by @adron
rtc@284000 {
compatible = "marvell,armada-8k-rtc";
reg = <0x284000 0x20 0x284080 0x24>;
reg-names = "rtc\0rtc-soc";
interrupts = <0x00 0x4d 0x04>;
};
But it's not in the patch.
Shouldn't it be added?
I'm on master with 6.1 patch;
root@MikroTik:~# dmesg |grep rtc
[ 1.247828] armada38x-rtc f2284000.rtc: registered as rtc0
[ 1.253351] armada38x-rtc f2284000.rtc: setting system clock to 2105-11-01T13:45:26 UTC (4286526326)
It's not part of adrons's nor robimarko's DTS, but feel free to test and report back. I'm not sure the DTS is supposed to actually set the hardware clock.
Just keep in mind your observations from here in out might be skewed, since you reset the clock.
Internal RTC is useless without an external battery
I supposed so, yes. Thanks for confirming.
Were you able to look into the Marvel driver by any chance?
Sadly no, its on the TODO pile
I made some changes to the mtpoe_ctrl for RB5009UPr+S+IN:
I'll raise a merge request to the original repo, for now you can get is from https://github.com/prudy/mtpoe_ctrl.git, branch feature/RB5009UPr+S+IN.
10 posts were split to a new topic: Help compiling OpenWrt for RB5009
Hi.
First of all thank you to all of you that made this possible with your hard work.
I've tried to compile my own build (23.05 with applied patch set for it) but if I set
CONFIG_TARGET_KERNEL_PARTSIZE=5
CONFIG_TARGET_ROOTFS_PARTSIZE=10
build fails with this error.
Creating 4.0 filesystem on /home/debian/openwrt/build_dir/target-aarch64_cortex-a72_musl/linux-mvebu_cortexa72/root.squashfs, block size 262144.
Pseudo file "dev" exists in source filesystem "/home/debian/openwrt/build_dir/target-aarch64_cortex-a72_musl/root-mvebu/dev".
Ignoring, exclude it (-e/-ef) to override.
[========================================================================================================================================\] 1995/1995 100%
Exportable Squashfs 4.0 filesystem, xz compressed, data block size 262144
compressed data, compressed metadata, compressed fragments,
no xattrs, compressed ids
duplicates are removed
Filesystem size 9940.00 Kbytes (9.71 Mbytes)
24.57% of uncompressed filesystem size (40448.85 Kbytes)
Inode table size 16080 bytes (15.70 Kbytes)
20.10% of uncompressed inode table size (79984 bytes)
Directory table size 22946 bytes (22.41 Kbytes)
42.66% of uncompressed directory table size (53787 bytes)
Number of duplicate files found 298
Number of inodes 2417
Number of files 1947
Number of fragments 98
Number of symbolic links 300
Number of device nodes 1
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 169
Number of hard-links 0
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)
/home/debian/openwrt/staging_dir/host/bin/make_ext4fs -L rootfs -l 10485760 -b 4096 -m 0 -J -T 1698952057 /home/debian/openwrt/build_dir/target-aarch64_cortex-a72_musl/linux-mvebu_cortexa72/root.ext4 /home/debian/openwrt/build_dir/target-aarch64_cortex-a72_musl/root-mvebu/
Creating filesystem with parameters:
Size: 10485760
Block size: 4096
Blocks per group: 32768
Inodes per group: 640
Inode size: 256
Journal blocks: 0
Label: rootfs
Blocks: 2560
Block groups: 1
Reserved blocks: 0
Reserved block group size: 7
error: make_file: failed to allocate inode
make[5]: *** [/home/debian/openwrt/include/image.mk:344: /home/debian/openwrt/build_dir/target-aarch64_cortex-a72_musl/linux-mvebu_cortexa72/root.ext4] Error 1
make[5]: Leaving directory '/home/debian/openwrt/target/linux/mvebu/image'
make[4]: *** [Makefile:18: install] Error 2
make[4]: Leaving directory '/home/debian/openwrt/target/linux/mvebu'
make[3]: *** [Makefile:11: install] Error 2
make[3]: Leaving directory '/home/debian/openwrt/target/linux'
time: target/linux/install#55.41#28.64#73.68
ERROR: target/linux failed to build.
make[2]: *** [target/Makefile:30: target/linux/install] Error 1
make[2]: Leaving directory '/home/debian/openwrt'
make[1]: *** [target/Makefile:24: /home/debian/openwrt/staging_dir/target-aarch64_cortex-a72_musl/stamp/.target_install] Error 2
make[1]: Leaving directory '/home/debian/openwrt'
make: *** [/home/debian/openwrt/include/toplevel.mk:232: world] Error 2
If I set these to
CONFIG_TARGET_KERNEL_PARTSIZE=15
CONFIG_TARGET_ROOTFS_PARTSIZE=1024
the compile is successful.
Are 15 and 1024 values OK.
Update - I've changed the values to 5 and 1024.
Probably CONFIG_TARGET_ROOTFS_PARTSIZE=10 was too small for my packages to fit.
Flashed successfully and working OK.
They're values in MiB indeed so 10 is a bit close if your build is fat:
Is 15 MiB the max value for Kernel partition size?
The kernel sits on the NOR flash, which is 16 MiB. 1 MiB is reserved for the bootloader, so you have 15 left. That's plenty for just the kernel.
@everyone I would like for those who are willing to share a recent image for this RB5009. Unfortunately I'm too new to build it myself! If one of you want to share it I would be delighted. Thanks in advance !
Hi @segal_72 i've got a recent (last saturday) snapshot build 23.05 (5.15.137) with @Borromini's patch found on the RB5009 wiki. Pretty default with Wireguard and NextDNS packages added. Its been running smooth for the last couple of days. If interested send me a DM.
I am trying to set up RSS on this platform to distribute traffic across all queues and cpu cores. I have enabled receive-hashing with ethtool -K, but still only a single queue is used.
Interestingly, rxq 0 is used when receive-hashing is off and rxq 2 is used when receive-hashing is on (determined with ethtool stats).
The output of ethtool -x and ethtool -n is as expected.
To me it looks like the classifier is not working correctly. Is this a known bug? Is it possible that this is related to DSA?
It looks like it is indeed releated to DSA. The parser of the Armada 7040 Packet Processor is unable to parse the DSA-encapsulated packets. Manually adding a 4 byte offset in the MVPP2_PE_DSA_DEFAULT parser entry (which is used as a fallback if no DSA tag could be found) fixes the issue.
After further investigation it looks like the appropriate parser entries for DSA encapsulated packets is disabled by default. These can be enabled by changing prs_tag_mode_set([..], MVPP2_TAG_TYPE_MH) to MVPP2_TAG_TYPE_DSA.
Hi, curious, where is this MVPP2_TAG_TYPE_DSA set ?