**** BEGIN LOGGING AT Sun Jul 07 03:00:53 2019 Jul 07 14:21:49 heads up - luci appears quite broken to me as of latest merge Jul 07 14:30:57 https://pastebin.com/kynNscFh Jul 07 14:31:54 also status overview page has no data. similarly firewall status page Jul 07 14:54:22 greearb_: Hi, When i use ath10k-ct 5.2, I am seeing this warning when it registers against mac80211 form 5.2: https://pastebin.com/B0rnyjsJ with ath10k-ct 4.19 it works Jul 07 14:55:31 it is hitting this: https://elixir.bootlin.com/linux/v5.2-rc7/source/net/wireless/core.c#L621 Jul 07 15:01:38 Hi, I'm trying to get openwrt running on a GS108Tv2. It has a BCM53312 CPU, 16MB flash, 64MB RAM. I found a serial port and found out that it uses the CFE bootloader. Jul 07 15:02:23 Is there an easy way to identify wether this CPU is MIPS or ARM? I would guess it is MIPS due to the CFE bootloader. Jul 07 15:03:52 Nevermind it is MIPS due to the bootlaoder output Jul 07 15:05:10 I just build openwrt for the target Jul 07 15:07:18 (Broadcom BCM47xx/53xx (MIPS), Generic, Broadcom SoC, all Ethernet, No WiFi, ramdisk) and wanted to boot it via cfe network boot (boot -tftp -elf 192.168.0.9:/vmlinux-initramfs.elf). But I get the error: Could not load 192.168.0.9:/vmlinux-initramfs.elf: Executable is wrong-endian, any ideas? Jul 07 15:11:08 I mean vmlinux-initramfs.elf is little endian, shouldn't this be correct? Jul 07 15:16:21 you're trying to port to an unmanaged switch? Jul 07 15:16:40 BCM53312 is only a switch and does not contain CPU capable of running Linux, if your device has 16MB flash and 64MB ram there is probably a difefernt CPU on the board Jul 07 15:17:36 there are likely clues to it in the cfe output Jul 07 15:19:03 Here is the boot output: https://pastebin.com/Q7K4U10a Jul 07 15:19:24 I'm pretty sure this isn't an unmanaged switch Jul 07 15:21:50 Hauke: someoner: it should be linux capable, but it's a bcm47xx type device in big endian mode, so currently unsupported Jul 07 15:22:23 KanjiMonster: ok thanks for the info Jul 07 15:23:11 I only took a look at https://dev.archive.openwrt.org/wiki/platforms and thought that means there are no bcm47xx with big endian Jul 07 15:23:26 you can switch it Jul 07 15:23:44 but I have never seen a brcm47xx in big endian mode Jul 07 15:23:51 this is probably for a diffeernt market Jul 07 15:26:14 don't all ARM and MIPS select endianness by gpio resistor at reset time? Jul 07 15:27:57 abcabc__: sometimes this signal is hard wired to some position, then you can not change it any more with a board or package change Jul 07 15:28:44 oh i see, it's a managed switch using the windows tools they provide Jul 07 15:29:05 actually it has a web interface Jul 07 15:29:17 I don't think that changing the endianess is an option. Wouldn't this break the bootlaoder? Jul 07 15:29:58 it would also likely break the connections to other chips on the board Jul 07 15:30:08 yes Jul 07 15:30:44 someoner: yeah no, your course of action would be to make bcm47xx/bcm53xx work in big endian (as a new (sub-)target) Jul 07 15:31:22 this is what I thought. Jul 07 15:33:05 should be a reasonable amount of work, as long as you know what you are doing ;) Jul 07 15:33:35 lack of wifi will simplify a few things Jul 07 15:35:14 to add usb storage support to one of the tiny ar71xx images, does one need a rebuilt kernel? Jul 07 15:35:39 or just package munging? Jul 07 15:56:29 One more question: should I use Generic, MIPS 74K or Legacy for the BCM53312? I would guess mips74k due to the gigabit ethernet. Jul 07 15:58:49 hmm? Jul 07 16:00:50 There are three subtargets for the BCM47xx target (https://openwrt.org/docs/techref/hardware/soc/soc.broadcom.bcm47xx#subtargets_in_barrier_breaker). I'm not sure which I should use as a base for my new subtarget Jul 07 16:02:24 The main difference appears to be the SSB vs BCMA, but I don't know which I have. Jul 07 16:21:54 someoner: the cpu type and speed more likely indicates mips 4k/bmips and ssb Jul 07 16:22:08 the hw support list claims tl-wr841n v14 works in snapshot but there is no v14 image in ar71xx/tiny Jul 07 16:22:48 here https://downloads.openwrt.org/snapshots/targets/ar71xx/tiny/ Jul 07 16:23:34 is it somewhere else? Jul 07 16:39:19 As a first quick hack I tried to change target/linux/brcm47xx/config-4.14 and target/linux/brcm47xx/config-4.19 to use big endian (XONFIG_CPU_BIG_ENDIAN=y), but for some reason vmlinux-initramfs.elf is again little endian. I did a git clean -fdx before the build, so it should be a clean build. What did I forget? Jul 07 16:49:39 There also is a CONFIG_SYS_SUPPORTS_BIG_ENDIAN. I'll try this Jul 07 17:06:45 I would like to update mac80211 to 5.23-rc7 in master, I just send a patch Jul 07 17:06:55 ath10k-ct 5.2 does not work for me Jul 07 17:07:02 ath10k-ct 4.19 works for me Jul 07 17:33:20 Another build and build_dir/target-mipsel_74kc_musl/linux-brcm47xx_mips74k/linux-brcm47xx_mips74k is still little endian :-/ Jul 07 17:34:24 err mipsel - mips endian litttle Jul 07 17:35:37 @ldir: thanks, I'll try this Jul 07 17:37:38 OK, I've changed mipsel to mips and started a new rebuild. Wish me luck Jul 07 18:03:57 Another build and build_dir/target-mips_74kc_musl/linux-brcm47xx_mips74k/vmlinux-initramfs.elf is again little endian. Any more ideas? (here are my current changes: https://pastebin.com/0JnJgwJC) Jul 07 18:13:39 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Jul 07 18:30:03 someoner: try deleting tmp/, some stuff in there isn't always properly regenerated on changes Jul 07 18:37:35 I now did a git clean -fdx (this also removed tmp/, and triggert another build. I'm not expecting any changes, but maybe I'm lucky. Otherwise I'll try out to build the malta target. It seems to have a big endian target Jul 07 18:39:28 jow: ping Jul 07 18:43:45 https://pastebin.com/4ZMy8A7j - improved, certain pages still not happy Jul 07 18:45:05 aparcar[m]: pong Jul 07 18:45:45 jow: after you've ponged aparcar[m] ^^^^^^^ :-) Jul 07 18:46:48 ah, dammit just seen latest pushes - I bet you've fixed it already Jul 07 18:47:55 do you mind mirroring firewal3.git to github so i can setup some CI? Jul 07 18:48:21 no time, sorry Jul 07 18:48:57 do you mind i create a repo and you update you mirror script at some point? Jul 07 18:49:51 jow: will you do a lede 17.01.8 or should I trigger it? Jul 07 18:50:04 or is there still something pending? Jul 07 19:05:35 someoner: the main big-endian target is ath79 Jul 07 19:05:51 Hauke: not sure what state the branch is in Jul 07 19:06:03 Hauke: also needs fixes to the gpg setup before we can trigger another build Jul 07 19:07:06 aparcar[m]: I cna look sometime this week, hopefully Jul 07 19:07:09 not before thursday Jul 07 19:07:09 jow I bet having 3 branches on the go at the same time is doing your head in! Jul 07 19:07:15 Another build and still no big endian (readelf -h build_dir/target-mips_74kc_musl/linux-brcm47xx_mips74k/vmlinux-initramfs.elf still returns little endian). I'm not sure what is wrong. Jul 07 19:07:42 @DonkeyHotei Thanks, I'll take a look Jul 07 19:08:00 How is it going people anyway? Jul 07 19:09:23 ldir: custom build? cannot reproduce Jul 07 19:10:14 yes - but I haven't built with your latest 5 commits to luci, so let me test again with that. Jul 07 19:10:15 Why will there be a .8 of the 17.xx branch? Jul 07 19:10:33 ldir: those are unrelated. on which pages do you observe the error? Jul 07 19:11:56 cgi-bin/luci/admin/statistics/collectd/network/interface Jul 07 19:12:43 cgi-bin/luci/admin/statistics/collectd/general/sensors Jul 07 19:13:51 ldir: index status overview is working? Jul 07 19:14:11 ldir I am running a ath79 build withluci now. Jul 07 19:14:36 jow: yes Jul 07 19:18:57 someoner: you have to change this to maek it big endian: ARCH:=mips Jul 07 19:19:27 then the toolchain will be build for MIPS BE Jul 07 19:19:38 jow: ok no problem take your time Jul 07 19:20:54 Hauke: I think I did this: https://pastebin.com/0JnJgwJC Jul 07 19:21:08 I modified target/linux/brcm47xx/Makefile and replaced mipsel with mips Jul 07 19:22:03 someoner: then it shuild build for MIPS BE Jul 07 19:22:20 but I think you will have to fix some drivers Jul 07 19:23:23 readelf -h build_dir/target-mips_74kc_musl/linux-brcm47xx_mips74k/vmlinux-initramfs.elf still says little-endian Jul 07 19:24:33 and CFE is still complaining "Could not load 192.168.0.9:/vmlinux-initramfs.elf: Executable is wrong-endian" Jul 07 19:25:14 I'm probably doing some dumb mistake... Jul 07 19:29:10 still stuck on this a week later… if my env/kernel-config contains "CONFIG_NFT_REJECT_IPV4=m" and "CONFIG_NFT_REJECT_IPV6=m", what would cause these to get turned off in the linux-4.19.56/.config file? Jul 07 19:29:53 someoner: CONFIG_BCM47XX in arch/mips/Kconfig only selects SYS_SUPPORTS_LITTLE_ENDIAN Jul 07 19:30:07 it also has to select BIG endian Jul 07 19:34:02 wtf… why do we need swapping in busybox enable? Jul 07 19:35:11 swapping on a real-time/embedded/memory constrained device seems antithetical... Jul 07 19:36:55 jow: have you just fixed it? Jul 07 19:37:00 Hauke: thanks, but where do I find this? Jul 07 19:37:08 say thanks to the historical arcitechturing of stuff for "need" for swap Jul 07 19:42:02 oh, this is at the linux kernel Jul 07 19:42:22 Hi what is the best way to clean up my build env? Jul 07 19:42:23 ldir: should be fixed in HEAD now Jul 07 19:42:52 excellent - will pull & test :-) Jul 07 19:43:23 I want to nuke the lot and start from scratch! Jul 07 19:43:34 philipp64: you can use a compressed ramdisk to swap on ;-) Jul 07 19:44:01 that is want zram-swap does Jul 07 19:44:03 Is it make distclean? Jul 07 19:44:05 *what Jul 07 19:44:34 .not that you don't have zram available also nowadays, but still not the "issue" Jul 07 19:45:03 and usually and oftentimes things just work nice without swap too, but there is allways something that does not Jul 07 19:48:05 Tapper: distclean is the nuclear option indeed. Jul 07 19:49:33 I'd check 'git status' is clean as well Jul 07 19:59:08 I mite just do rm openwrt lol Jul 07 19:59:43 did you break it again Jul 07 19:59:56 Yeah lol Jul 07 20:00:20 xD Jul 07 20:00:22 Just my build env not my routers lol Jul 07 20:00:22 how did you manage that Jul 07 20:00:26 oh Jul 07 20:00:35 that's something at least Jul 07 20:00:41 haha Jul 07 20:01:13 i am seeing all kinds of weird shit with my 19.07 tree... how i can't sysupgrade my unifi aps anymore from one 19.07 build to another, sysupgrade chokes on the model info all of a sudden Jul 07 20:06:22 jow: confirm fixed :) Jul 07 20:07:47 great, thanks Jul 07 20:13:39 ldir I did a make distclean, but there is still a lot of files in my openwrt dir. Jul 07 20:14:23 what does git status say? Jul 07 20:15:14 a distclean will get you back to the status as if you had just cloned the openwrt git repo Jul 07 20:15:57 git status should come back with "nothing to commit,. working tree clean" Jul 07 20:17:09 if if says "untracked files present" then you have files in your local directory that are extra to the git tree. Jul 07 20:20:28 at some point, assuming you probably don't really have local/ private branches/ commits, it might be easier to start with a fresh git clone though Jul 07 20:21:22 https://www.explainxkcd.com/wiki/index.php/1597:_Git Jul 07 20:21:58 git reset --hard HEAD should wipe everything untracked no? Jul 07 20:22:59 ldir working tree clean Jul 07 20:24:01 Borromini: no, untracked files will remain Jul 07 20:24:04 thanks both Jul 07 20:24:16 ldir: hm. Jul 07 20:24:23 try it ;-) Jul 07 20:24:28 must have done something else wrong with another git tree Jul 07 20:24:39 no... i had all my saltstack in a git tree Jul 07 20:24:42 did a hard reset Jul 07 20:24:47 all my unsaved crap gone. Jul 07 20:24:55 but yeah, probably not untracked files Jul 07 20:30:47 i just sysupgrade a UniFi AP and it mysteriously gave up its static IP for a DHCP one Jul 07 20:31:02 what the hell is wrong >_> Jul 07 20:31:04 jow: do you mind I activate CI on luci? Jul 07 20:47:23 thanks to Hauke I got a big endian elf. I was able to execute "boot -tftp -elf 192.168.0.9:/vmlinux-initramfs.elf", but it immediatly throws eceptions, like invalid opcode (https://pastebin.com/5Ncvz8ds) Jul 07 20:48:14 This seems pretty strange to me. Is there a way to verify that the device is using big endian? Jul 07 20:48:46 (apart from CFE not accepting LE) Jul 07 20:52:25 someoner: you probably build for MIPS32R2, but yourt CPU only supports r1 Jul 07 20:53:08 someoner: try the settings from the legacy sub target Jul 07 20:53:18 it should build an image with mips32r1 only Jul 07 20:53:51 thanks, I'll try this! Jul 07 20:54:34 the try point also looks strange Jul 07 20:54:42 I do not know if your image is adapted for that Jul 07 21:35:38 I tried to boot the legacy target: https://pastebin.com/a92nyaAG Jul 07 21:36:01 looks different, but is still crashing Jul 07 21:43:44 I just took a closer look at the vendor firmware. After extraction I found an elf, which indeed is a Big-Endian file. So it is confirmed that big endian is the way to go Jul 07 21:44:06 someoner: B8005FFC is the SSB_IDHIGH register of core 5 ( https://elixir.bootlin.com/linux/latest/source/include/linux/ssb/ssb_regs.h#L157 ) - so probably the buserror happended here -> https://elixir.bootlin.com/linux/latest/source/drivers/ssb/scan.c#L342 Jul 07 21:49:17 KanjiMonster: I'm amazed how fast you found this! Jul 07 21:52:26 is there any way to verify that the cpu has the SSB and not BCMA? I couldn't find any datasheet Jul 07 21:52:53 someoner: currently the ssb code uses readl/writel for accesses, which assumes LE byte order; you could try changing these to ioread32be/iowrite32be to switch to BE, in case the ssb registers are using native endian Jul 07 22:01:42 KanjiMonster: sounds like a reasonable idea. Do you think there is a good chance to get this to work if we don't have a datasheet? Jul 07 22:03:00 someoner: yes, especially since you can get GPL sources for bcm53xx based switches Jul 07 22:03:27 though getting it into clean code is probably a bit more work Jul 07 22:04:03 someoner: also you might want to enable EARLY_PRINTK (you need to remove the "depends on arm" in config/Config-kernel.in first though) Jul 07 22:04:12 I totally forgot to look for gpl sources. Jul 07 22:06:58 regarding the kernel patching: At the moment I'm creating patches to place them into "/home/fvollmer/openwrt/openwrt/target/linux/brcm47xx/patches-4.14" an then I rebuild. Is there a faster way? Jul 07 22:07:47 and EARLY_PRINTK sounds like a nice idea Jul 07 22:11:18 I usually just edit the extracted sources in build_dir/target-*/target-*/linux-*/linux-4.*/, as long as you don't touch anything in target/linux/*/files or target/linux/*/patches you are fine Jul 07 22:11:55 and then just run "make"? Jul 07 22:12:15 make target/linux/install will just rebuild the kernel and images, so it's the quickest build target to rebuild the ramdisk kernel Jul 07 22:14:40 thanks again! This should reduce my build time. I hated to wait >30 minute for a complete build Jul 07 23:32:56 The simple replacement of readl/writel with readl/writel didn't change anything. Exactly the same exceptions. Jul 08 02:45:10 Hauke: I have a 0.5 TB NVMe stick, so I suppose I could swap… I just don't see the point. **** ENDING LOGGING AT Mon Jul 08 02:59:58 2019