**** BEGIN LOGGING AT Mon Apr 13 02:59:57 2020 Apr 13 03:48:04 pepe, I used the realtek as STA only Apr 13 06:21:58 *yawn* Apr 13 06:22:10 ldir: ask them how they found those memory issues please Apr 13 07:00:53 dumb question - dumb quesiton - I am asked to try out this patch: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2020-April/143270.html ... what's the standard method to do so without removing html from a file downloaded with curl? Apr 13 07:09:27 mrkiko: erm copy paste that into a .patch file Apr 13 07:10:47 that dts change need to also be applied elsewhere Apr 13 07:11:11 mrkiko: it's ugly but i'm not finding any patchwork counterpart for that mailing list... So it's handywork like mangix says i'm afraid Apr 13 07:13:38 that patch is funny Apr 13 07:13:52 going back from using dts to driver assignment Apr 13 07:13:58 of irqs Apr 13 07:15:11 do you still have mt7621 devices mangix ? Apr 13 07:15:17 I do not Apr 13 07:15:37 nor any mt76 wireless stuff Apr 13 07:19:59 mangix, Borromini: thank you guys; I added the patch to ramips 5.4 patches in the tree, and rebuilding now Apr 13 07:20:33 I used curl, and with nano stripped html around the patch Apr 13 07:21:33 in bocca al lupo. Apr 13 07:22:04 mangix: can you xplain the patch better to me? From description I can't understand exactly the sense of it Apr 13 07:22:17 Borromini: crepi! :) :) Apr 13 07:22:38 Borromini: when I read italian text here I remain kinda impressed :D Apr 13 07:22:46 my word-parsing mechanism resets itself Apr 13 07:23:29 oh dear, my new network gear arrived. the switch is slighty overkill and the AP is one huge heatsink :D Apr 13 07:23:47 sometimes BTW mt76 needs to reset the cards inside some of those devices, then them work; I guess this is not hardware issue but software/firmware one Apr 13 07:24:19 mrkiko: because it detects another language? Apr 13 07:24:24 hey stintel Apr 13 07:26:26 Borromini: ahaha yes, a language that it doesn't expect! :) Happy to read italian sometimes :D Apr 13 07:26:34 hi stintel ! Apr 13 07:26:51 mornin' folks :) Apr 13 07:27:35 starting the week with learning a new CLI (Huawei) Apr 13 07:29:53 is it 中国 Apr 13 07:30:59 haha no Apr 13 07:31:17 but it uses display instead of show, and quit instead of exit. going to take some getting used to Apr 13 07:31:42 lol. command lines and their idiosyncracies eh Apr 13 07:31:46 stintel: what kind of equipment is it? Apr 13 07:33:42 S6720-32C-PWH-SI-AC (24x MultiGigabit ethernet w/ PoE++) and ap7060dn (8x8 802.11ax AP with 10GbE uplink) Apr 13 07:35:07 8x8 o_O Apr 13 07:35:27 yeah insane Apr 13 07:36:31 gigabit was becoming a bottleneck so I decided it was time for an upgrade Apr 13 07:40:22 stintel: oh, I dream about the day openwrt will run in that kind of hw Apr 13 07:45:17 ok guys, I should be doing something wrong, that patch fails Apr 13 07:45:21 due to hunk failure... Apr 13 07:45:57 Hunk #5 succeeded at 283 with fuzz 1. Apr 13 07:45:58 Hunk #6 FAILED at 344. Apr 13 07:54:54 stintel: next it will be giveup instead of quit Apr 13 07:56:46 mrkiko: what are you naming it? Apr 13 07:57:28 jow: nevermind the patch from yesterday, i'll send you a followup soonish Apr 13 07:57:31 dangole: ping Apr 13 07:57:34 mangix: 999-paraka.patch Apr 13 07:58:01 russell--: :D Apr 13 07:59:27 mangix: target/linux/ramips/patches-5.4/999-paraka.patch Apr 13 08:01:38 my guess is ou also need http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2020-April/143186.html Apr 13 08:02:38 mangix: ok, let's try it Apr 13 08:08:05 mangix: do you think he thinks I may apply other patches as well, just in case Apr 13 08:08:25 and how did you ttrack that one? Apr 13 08:16:36 mangix: ok, you where exactly right Apr 13 08:16:43 mangix: thanks Apr 13 08:27:45 so, I named the first patch - whe one powering off the phy properly to 997-paraka.patch, the second one, interrupt mapping, to 999-paraka2.patch; 997 fails Apr 13 08:31:31 mrkiko: can you pastebin 1) the error you get (failure indicating file and line etc.) 2) the contents of the file it fails to patch 3) the patch as you used it Apr 13 08:32:44 ok, as for 1 - it's one line Apr 13 08:33:55 mrkiko: i know, just pastebin the output you get as a first paste Apr 13 08:34:22 https://paste.debian.net/ e.g. Apr 13 08:38:17 Borromini: http://ix.io/2hP9 Apr 13 08:42:04 separate pastes would have been readable... but hey Apr 13 08:43:19 mrkiko: there are only two patches, not three Apr 13 08:44:08 interrupt patch is second Apr 13 08:44:58 Borromini: sorry man... Apr 13 08:45:35 if (slot == 1 && tmp && !tmp->enabled) Apr 13 08:45:40 that's html garbage Apr 13 08:45:54 you need a better copy Apr 13 08:46:12 no wonder it's not applying Apr 13 08:46:14 mrkiko: let me give it a shot Apr 13 08:46:47 mangix: oh oh ... stupid me, I forgot about that thing. Why do you say it's only 2 patch? I have 2 patch oonly infact Apr 13 08:47:27 the fact is - if I used lynx I guess the text would have wrapped and that would have broken the code as well, but should take more care next time Apr 13 08:48:50 mrkiko: it's just messy all around, having to copy a patch like that Apr 13 08:49:11 jow: so the concept for buildbot staging trees would be to have builders like --and then do some filtering which to actually run? Apr 13 08:49:50 my .config - useless, but ... http://ix.io/2hPf Apr 13 08:49:55 jow: i"m wondering if for staging trees, something like gitlab would be easier Apr 13 08:50:21 Borromini: yes, infact I assumed there was a kind of ... tool, to do so Apr 13 08:57:08 jow: I also fixed the previous patch, please see the list here https://github.com/aparcar/buildbot/pull/3/commits Apr 13 09:09:09 mrkiko: https://marc.info/?l=linux-driver-devel&m=158675759519431&w=2 there's download raw button. Apr 13 09:09:46 should be applicable Apr 13 09:10:10 tmn505: thanks!!!! As a note - could you please check the latest comment @paraka sent in PR 2798 Apr 13 09:10:26 tmn505: because he now is indicating me more patches Apr 13 09:10:42 but I am confused as to what's on the tree and what is not Apr 13 09:12:28 if he's proposing other patches, then search them in archive https://marc.info/?l=linux-driver-devel, if he sent them to the linux-driver-devel mailing list Apr 13 09:13:00 I'm not familiar with ramips devices Apr 13 09:13:13 tmn505: thanks! Apr 13 09:20:53 * mrkiko is happier now :D Apr 13 09:26:02 mrkiko: the first patch paraka mentions is already in the openwrt tree as 0116-staging-mt7621-pci-use-builtin_platform_driver.patch Apr 13 09:26:46 yeah, I found it infact used only the 2 ones - Apr 13 09:27:07 i have numbered the two remaining patches 0120 and 0121 Apr 13 09:27:17 and i'm giving the compile a shot as we speak Apr 13 09:27:37 it works Apr 13 09:28:11 Borromini: thank you very much Apr 13 09:37:06 mrkiko: i'm seeing this but at least it works https://paste.debian.net/1140056 Apr 13 09:37:52 http://ix.io/2hPw and http://ix.io/2hPx are the plaintext patches (i numbered them 0120 and 0121) Apr 13 09:39:07 thank you man!! Apr 13 09:39:36 I followed tmn505 suggestion and I have them as well, that's why I said it works. thank you very much for your help really Apr 13 09:39:40 let's see what device does Apr 13 09:40:23 I find it interesting that me pinging the mt76-pcie guy caused a whole bunch of progress Apr 13 09:42:34 mangix: ?? Apr 13 09:43:06 thanks to all guys! going out for a moment Apr 13 09:44:06 :) Apr 13 09:45:34 mrkiko: paraka became aware of people having issues with the pcie driver after I pinged him in the ramips 5.4 thread Apr 13 09:46:20 lesson is: blogic was partially right in that the code was upstreamed in a hurry Apr 13 09:48:26 this doesn't take care of the r6220 issue that is worked around by upgrading the bootloader i take it Apr 13 09:49:03 what issue is that Apr 13 09:50:50 mrkiko was suffering from that Apr 13 09:51:07 additionally, at least the dir-860l breaks on the 5.4 bump as well Apr 13 09:52:04 https://forum.openwrt.org/t/optimized-build-for-the-d-link-dir-860l/948/1083 Apr 13 09:52:42 lzma error. hahahaha Apr 13 09:53:17 i'm missing the joke but i'm sure you'll fill me in :P Apr 13 09:53:49 lzma is a compression algorithm. and every manufacturer has their own broken implementation of it. Apr 13 09:54:13 I doub that's what's happening here, but it's still funny Apr 13 09:55:41 Did anyone figure out why ramips uboot fork fails to unlzma some images? Probably it's just that they're too big and overwriting some loader data or code? I know on my tiny device it's loading from flash just fine but initramfs is a no go. Apr 13 09:56:14 PaulFertser: so you have it the other way around huh? Apr 13 09:56:22 I guess one can try prepending OpenWrt lzma-loader to it and making an uncompressed uimage Apr 13 09:56:46 Borromini: yeah, on my device initramfs is unbootable while loading from flash works. Apr 13 09:56:48 mangix: i know what lzma is, didn't know it had so many broken implementations Apr 13 09:56:54 PaulFertser: go figure :-/ Apr 13 09:57:24 just got reminded Apr 13 09:57:36 I ported BearSSL to OpenWrt Apr 13 09:57:54 there are now + 1 SSL libraries Apr 13 09:59:02 Borromini: yeah on some bootloaders, you can't use a dictionary, other options must be relaxed, etc... Apr 13 09:59:07 :-/ Apr 13 09:59:12 hard to make a small image like that Apr 13 09:59:44 yeah. Apr 13 09:59:48 mangix: is lzma-loader problematic? Apr 13 09:59:56 dunno Apr 13 10:00:18 the EA6350 v3's bootloader apparently doesn't support lzma at all. so not much wiggle room with kernels either. a lot of fun. Apr 13 10:00:51 it looked like a device that could last for a while but with limitations like that it will be EOL pretty soon. Apr 13 10:02:05 on ramips/mt7621, loader-common has room for 31 MiB uncompressed kernel image (just looked it up). so that shouldn't be too tight Apr 13 10:04:12 hmm, interesting LZMA_TEXT_START is 0x82000000, so this won't work on 32MB RAM devices ... Apr 13 10:05:50 hmm, but looks ramips is only using that one for mikrotik Apr 13 10:06:51 * mangix has been out of the loop Apr 13 10:07:04 is ath79 using the upstream driver yet? Apr 13 10:07:15 *ethernet driver Apr 13 10:11:05 mangix: people tried it but then reverted Apr 13 10:11:27 mangix: because not many want to work on improving the upstream driver to be useful on all kinds of boards. Apr 13 10:12:08 And the old driver has all the hacks embedded... Apr 13 10:17:59 it also results in interrupt errors. at least when i used it last. Apr 13 10:42:20 PaulFertser: i've had a short dive into the GPL code of the R6220 and R6260 and i haven't seen any NAND read logic in the bootpath Apr 13 10:43:15 I have no idea what's going on woth the DIR-860L though. I have been booting 4M initramfs images on a nanoHD w/o issues whatsoever. Apr 13 10:43:42 fyi: ER-X also won't boot kernels >2M Apr 13 11:15:46 mrkiko: you need to modify the DTS Apr 13 11:16:19 notice the last patch how it modifies the DTS in the staging directory. you need to make the same changes to mt7621.dtsi Apr 13 11:57:03 mangix: thanks man! I'll do so right now Apr 13 11:57:14 mangix: didn't notice it, didn't read the patch... my bad Apr 13 12:12:02 mangix, Borromini: success Apr 13 12:12:08 thank you for the patience Apr 13 12:13:20 =) Apr 13 12:25:31 I tried enabling small_flash for ramips and mt7621 kernel goes from 2.4M to 1.7M. Apr 13 12:27:45 small_flash disables various features like cgroup/seccomp/namespaces/swap and removes debug symbols. Apr 13 12:36:31 :) Apr 13 12:39:16 the nice thing is that most of mt7621 hw comes with more tan enough resources for those features... except swap maybe. But still ... bootloader is bootloader Apr 13 12:42:29 mrkiko: And that's exactly why I'm hesitating :) Apr 13 12:42:58 I believe most people won't be running a container on mt7621 but swap and debug symbols are still quite useful. Apr 13 12:46:46 gch981213: debug symbols are disabled by default on releases though, afaik Apr 13 13:05:20 gch981213: do you know how the bootloader handles the NAND at all? Apr 13 13:06:20 either the GPL dumps from netgear are incomplete or there aren't any nand logic in the boot process at all. it just performs a bootm from FLASH_START + KERNEL_OFFSET Apr 13 13:09:48 blocktrron: Those code are embedded in common/cmd_bootm.c in that ancient hacky u-boot. Apr 13 13:12:34 oh wow, hacky is no word for this mess Apr 13 13:14:18 gch981213: and one of the worst things is - we are going to meet this same issue on next bump. I know, most devices won't have such a long lifetime maybe, but ... Apr 13 13:16:57 gch981213: something different - do you plan submitting the ath79 spi-mem patch upstream? Apr 13 13:18:21 mrkiko: agree. 1.7M isn't far away from 2M and I didn't enable all kmods yet. Apr 13 13:19:23 blocktrron: That patch isn't suitable for upstream. Technically it should be implemented using spi-mem dirmap api but spi-nor driver doesn't support it yet. Apr 13 13:39:36 gch981213: What if we build all network drivers as modules? Apr 13 13:40:09 dengqf6: Tried. 2.4M->2.2M. Apr 13 13:40:36 built with DSA and mtk_eth_soc as modules. Apr 13 13:40:45 phylink? Apr 13 13:41:33 gch981213: what kind of flash does it have ? Apr 13 13:41:46 you could try using lzma-loader and add spi flash support Apr 13 13:41:52 ah this had ubi right ? Apr 13 13:43:36 dengqf6: That already becomes a module when selecting NET_DSA=y Apr 13 13:45:00 blogic: r6220 is a nand router. Apr 13 13:47:32 gch981213: but, do you have an idea how spread this problem is? Apr 13 13:48:11 gch981213: or, in other words, did you replace the bootloader in your development devices because of this problem or only for confort reasons? Just to understand how wide is the device number Apr 13 13:51:11 mrkiko: I'm not hit by it. However all 3 of my mt7621 boards are using spi-nor and running latest u-boot 2018.09 from mediatek. Apr 13 13:54:09 gch981213: so, presumably we know R6220 and DIR-860B are hit or am i wrong? Apr 13 13:54:23 mrkiko: correct. Apr 13 13:55:00 and I guess we have no alternate bootloader for the dir-860 Apr 13 13:56:43 mrkiko: That one ca be easily solved using lzma-loader as suggested by blogic. Apr 13 13:57:00 mrkiko: dir-860l is SPI based Apr 13 13:57:07 ah, should scroll Apr 13 13:57:09 dir-860l uses spi-nor and the first 4M of spi-nor is mapped in memory Apr 13 13:59:43 I don't understand how R6220 u-boot managed to decompress without error while corrupting kernel code. Apr 13 14:00:16 The only wild guess I have is that u-boot writes something to memory after extracting kernel. Apr 13 14:02:05 are you aware whether or not the nand implementation changed in subsequent U-Boot releases? Apr 13 14:02:51 gch981213: when you talk about lzma-loader, do you mean to have stock u-boot chainload it? Apr 13 14:02:57 The only thing I can offer is my 3 u-boot dumps of the 3 devices I have Apr 13 14:03:31 but I suspect they are the same - differencesstarts around 272k or so Apr 13 14:04:34 gch981213: so you mean - it does something after kernel extraction to "compensate" the corruption some how? Apr 13 14:05:43 mrkiko: there is some kind of sercomm bootwrapper around the bootm call on these netgear boards, however it is not part of the GPL dump Apr 13 14:06:29 blocktrron: thank you; and btw - do you have an idea of the contents of SC-PID ? Apr 13 14:07:24 Borromini: correct. just let u-boot load the tiny lzma-loader and lzma-loader can load the actual kernel afterwards. Apr 13 14:07:46 SC = sercomm I guess, PID = product id or something, for my 3 devices I have 3 different sc-pid partitions Apr 13 14:07:55 gch981213: ok :) thanks for clarifying Apr 13 14:08:32 gch981213: edgerouter might be suffering from a similar problem. See: https://forum.openwrt.org/t/newest-snapshot-killed-my-edgerouterx/60214/20 Apr 13 14:08:49 initramfs boots, flashed image does not Apr 13 14:08:54 mrkiko: "compensate"? I mean it may write to a fixed memory location to pass something to stock kernel. Apr 13 14:09:09 Borromini: I've posted the bootlog of an ER-X earlier today, it's the same story there Apr 13 14:09:12 gch981213: thanks; Apr 13 14:09:24 gch981213: so until now we where lucky Apr 13 14:09:25 blocktrron: ok. i missed that probably. sorry. Apr 13 14:09:59 blocktrron: No idea. I only have one u-boot 1.1.3 source code. Apr 13 14:10:18 lovely Apr 13 14:11:00 and the other u-boot 2018.09 is only in latest mediatek sdk released at the end of last year. Apr 13 14:11:45 This is a completely rework and I believe there's no router on the market with this new u-boot currently. Apr 13 14:16:22 any idea on what the Sercomm wrapper does? Apr 13 14:20:48 mrkiko: tools/firmware-utils/src/mksercommfw.c just adds header or footer in specific format Apr 13 14:21:10 mrkiko: hwid, hw and sw versions, magic Apr 13 14:21:30 And checksum Apr 13 14:22:54 Sercomm is some ODM that builds stuff for Netgear it appears Apr 13 14:23:24 PaulFertser: thank you! Apr 13 14:23:28 PaulFertser: interesting Apr 13 14:23:38 Borromini: oh, it seems it builds also its own devices Apr 13 14:45:59 Hello! I jave a device to which i would like to port openwrt to. I'm trying to wrtie a dts file and i know the flash layout. I'm unable to find gpio for leds but thst's not important for me atm. What i don't understand is the relationship beween ar9330 and ar7240 Apr 13 14:46:43 U-boot says "AP121-2MB (ar9330) U-boot" (flash is actually 8MB, but it is a cheap chine se device, they probably recycled the u-boot target) Apr 13 14:47:04 but the u-boot promp is "ar7240>" Apr 13 14:47:54 /proc/cpuinfo says "system type : Atheros AR9330 (Hornet)" Apr 13 14:48:08 so i should write it as a ar9330 target, right? Apr 13 14:48:35 aldoaldo: correct. it should be ar9330. Apr 13 14:50:33 so, calling the file target/linux/ath79/dts/ar9330_ziking_cpe46b.dts makes sense Apr 13 14:52:51 other than the mtd layout, what it is fundamental to make it boot? i mean, leds and even network interfaces may come later, other initialization params should be the same of other board with the same soc? Apr 13 15:10:41 aldoaldo: I generally, try... but before doing anything, it's a good idea to backup all the flash Apr 13 15:10:58 mrkiko: i have already done it, both via dd and via a soic clip :) Apr 13 15:11:20 :D GREAT Apr 13 15:11:34 currently, i have a command injection on the original firmware (which by the way is openwrt based) so i;'m trying to collect as much info as i can Apr 13 15:12:08 I guess vendor implemented it in ar71xx Apr 13 15:15:43 tmn505: I tried my espressobin again and it is very unstable, it booted up successfull after about 10 tries, it crahed always at a different position Apr 13 15:16:00 it worked 2 years ago stable, with the SW from that time Apr 13 15:16:29 do you laos have these problems? did you upgrade the bootloader? the bootloader is currently working stable ;-) Apr 13 15:19:08 so uh, I know ramips/5.4/dsa is still a wip, but does the known list of issues include .1q tags not working and other weirdness like some traffic exiting the wrong ports occasionally? Apr 13 15:28:37 ramips on 5.4 is wild :D Apr 13 15:28:49 yes :P Apr 13 15:28:56 its uh, "interesting" Apr 13 15:29:21 it actually works for most part but seems to randomly get very confused Apr 13 15:30:13 what device? Apr 13 15:30:51 er-x-sfp, also using it on a mir3g but I haven't noticed anything odd with that (all ports in the same bridge though) Apr 13 15:31:02 whereas er-x has wan/lan Apr 13 15:31:21 jwh_: so you're using sfp directly from openwrt!! Apr 13 15:31:29 no, sfp doesn't work yet Apr 13 15:31:31 now that it's supported1 Apr 13 15:31:45 at least, its not being detected Apr 13 15:31:47 oh, I saw some log of it working in the PR Apr 13 15:31:56 I don't think its been merged yet right? Apr 13 15:32:03 Rene__: any hint? Apr 13 15:32:04 mrkiko: if you know, once i compile the opwrt image, how do i get the address for bootcmd0=bootm 0x9f380000 ? Apr 13 15:32:27 sfp would be nice, but for now I'd just take copper ports Apr 13 15:32:43 what do you mean? 0x9f380000 seems an address on flash Apr 13 15:37:23 so yeah tags aside, it actually seems to work for a some time (so far about 13 hrs), then gets really confused Apr 13 15:37:35 doesn't seem to be a trigger like a config change Apr 13 15:39:40 today was the fun one, it thought it was sending traffic out of the port but it wasn't really, then it booted up with network config missing after soft reboot (along with some spurious squashfs errors) - but it seems to require ubifs recovery after every reboot Apr 13 15:41:46 mirko: that's the current layout bootargs=console=ttyS0,115200 root=31:02 rootfstype=squashfs,jffs2 init=/bin/init mtdparts=ar7240-nor0:64k(u-boot),64k(u-boot-env),3456k(rootfs),1024K(uImage),3456k(rootfs1),64k(NVRAM),64k(ART) Apr 13 15:42:17 my idea is to join the three middle partitions Apr 13 15:42:53 so the kernel position will change within a non stock image, i believe they use the second rootfsa for recovery Apr 13 15:44:27 aldoaldo: ? Apr 13 15:44:40 so in theory, in my dts file i'll write the something like mtdparts=ar7240-nor0:64k(u-boot),64k(u-boot-env),7936k(openwrt_suqashfs),64k(NVRAM),64k(ART) Apr 13 15:45:45 sorry mirko if i don't make much sense, i got into openwrt images a couple of days ago, i read some commit which add supports to similar boards in order to understand what to do but i'm still a bit lost Apr 13 15:46:28 aldoaldo: huh, that's nasty. You probably will need to change the uboot environment so that the kernel is right after u-boot-env. Apr 13 15:46:35 and, after that i should change my u-boot-env parameters in order to boot the new image Apr 13 15:46:43 aldoaldo: the partition should be called "firmware" btw Apr 13 15:47:38 Thank you PaulFertser, so the bootm parameter should be the address of the beginning of the firmware partition? Apr 13 15:51:52 aldoaldo: yes Apr 13 15:58:15 ~~/3 Apr 13 16:06:05 PaulFertser: can you please whether this dts makes sense to you? https://0bin.net/paste/BU4kzrLmtHXEKLWi#Vxva4ELxz-Htlo6nlB4nVfYqWRqqA4I+mIE64tXu6IS Apr 13 16:08:21 Also, i'm not sure whether the mac address are all in the art ore also some are in the nvram, but i'd like to boot a working image first and then work on the interfaces later, so it may be just a better idea to completely remove the interfaces related sections? Apr 13 16:08:34 aldoaldo: if you do not need to modify uboot env and "nvram" from openwrt I'd make them read-only. Apr 13 16:08:57 aldoaldo: re mac address, you'll see it in hexdump, and you already have full dump on your host computer. Apr 13 16:09:20 blocktrron: ping - could you try to adopt this to r6220 and see if problem solved? https://paste.ubuntu.com/p/BfYB9thhpz/ Apr 13 16:09:24 aldoaldo: I suggest you build an initramfs image and try running it from RAM. Apr 13 16:10:57 I had a wrong impression that lzma loader must read data from flash. It turns out that lzma-loader can also link the actual kernel with it and extract from ram. Apr 13 16:11:41 *adopt->adapt Apr 13 16:12:12 PaulFertser: i just checked and the mac address are all in the art partition, the nvram partition is a tar archive with proprietary system config files like /config/snmp_agent.conf Apr 13 16:12:21 gch981213: i can try, however this would still overwrite the uImage U-boot loaded to RAM wouldn't it? Apr 13 16:12:34 hmm, theuImage is uncompressed, so i guess no Apr 13 16:12:39 I guess that i can remove it as it doesn't contain initialization info? Or does openwrt need something like that too? Apr 13 16:13:24 aldoaldo: then you might want to use appropriate offsets for all mac addresses. While at it, check what mac is used by the vendor firmware for lan, wan and wifi so that with OpenWrt they all match. Apr 13 16:13:41 That's a good idea, thank you! I'll do it now Apr 13 16:13:53 aldoaldo: nvram can be merged if get auto-recreated by vendor firmware if someone decides to downgrade. Apr 13 16:14:37 blocktrron: lzma-loader copies itself elsewhere before extracting. Apr 13 16:14:38 PaulFertser: is that a requirement in order to be merged inside openwrt? Apr 13 16:15:16 aldoaldo: no, but more flash space is better than less Apr 13 16:15:40 so this should work as long as u-boot copies 2.4M lzma-loader with kernel into memory without corrupting it. Apr 13 16:15:43 Because the actual manufacturer of this device doesn't exists on the internet, it's pcb has zero results on google and their wbesite doesn't exists Apr 13 16:16:22 aldoaldo: heh, well, you can try zeroing the nvram partition and see if the vendor firmware handles that. Apr 13 16:16:31 at this point i'm expecting some shit like "unsupported compression method: none" or something along those lines. Apr 13 16:16:38 So they actually don't distribute the original image anywhere i know of, furthermore, i would like to ask for u-boot sources under gpl license but it looks like the only way to contact them is going shenzen haha Apr 13 16:16:43 will give it a shot after trying to find something to eat Apr 13 16:20:26 DRAM: smem ram ptable found: ver: 1 len: 4 Apr 13 16:20:27 2 GiB Apr 13 16:20:47 great, that's the AP7060DN so the 256MB on techinfodepot is wrong Apr 13 16:21:10 read content=/modules/4.1.51/net/wifi_module.ko,len=35. Apr 13 16:21:13 not even that ancient Apr 13 16:22:01 well it's more so that's good no? Apr 13 16:23:53 yes, that's why I said great Apr 13 16:24:07 I should have said awesome Apr 13 16:30:42 what i still don't understand is bootcmd=bootm 0x9f380000, that address is too big both for flash and ram? Apr 13 16:30:43 stintel: the factor of 8 difference sounds suspiciously like it means 2 gigabits Apr 13 16:31:22 SDRAM Memory Size : 2048 M bytes Apr 13 16:31:37 that sounds less ambiguous ;-) Apr 13 16:31:38 you got me scared there for a moment :P Apr 13 16:31:59 aldoaldo: it's where the flash is mapped Apr 13 16:32:07 ok so this beauty is going to run OpenWrt some day Apr 13 16:33:16 stintel: what is this device? Apr 13 16:33:44 ah, /me learns to read Apr 13 16:34:35 8x8 802.11ax AP with 10GbE uplink Apr 13 16:35:42 * russell-- assumes it sends all your data to the peoples liberation army ;-) Apr 13 16:35:42 aldoaldo: on ath79 chips, spi-nor is mapped to a 16M space starting from 0x1f000000. i.e. A memory read from 0x1f380000 returns data from flash at offset 0x380000. Apr 13 16:36:06 russell--: ;) Apr 13 16:36:36 I could probably put it on an isolated vlan and run tcpdump for some time to see if it tries to phone home Apr 13 16:37:02 gch981213: so should i also start the address in my dts files like that? Apr 13 16:37:15 aldoaldo: no. Apr 13 16:38:19 ok, thanks Apr 13 16:45:33 russell--: won't be too farfetched. Hello BGP :P Apr 13 16:45:56 * Borromini just finished reading 'Pax Sinica' and it doesn't paint a happy picture Apr 13 16:58:43 It looks like the oem firmware just adds 1 to the primary interface mac Apr 13 16:59:01 can i simply do mtd-mac-address = <&art 0x0> + 1; ? Apr 13 17:11:59 Hauke: my board is running fine, for now. I'm using factory U-Boot which is 2017.03-armada-17.10. You can still download it from http://web.archive.org/web/20200224175329/http://espressobin.net/tech-spec/, if You don't want to flash it, use UART or SATA images, check the wiki how to use them. Apr 13 17:13:28 But alas, we will have to provide updates for 5.4 kernel. I'm seeing these messages: Apr 13 17:13:40 mvebu-a3700-comphy d0018300.phy: unsupported SMC call, try updating your firmware Apr 13 17:13:49 phy phy-d0018300.phy.2: phy poweron failed --> -1 Apr 13 17:13:59 ahci-mvebu: probe of d00e0000.sata failed with error -1 Apr 13 17:14:49 tmn505: I am still using u-boot 2015.01-armada-17.02.0-g8128e91 Apr 13 17:14:54 my factory default Apr 13 17:15:27 I also see the SMC message, I think the kernel will just use the old method Apr 13 17:15:28 There are addition for COMPHY support in 5.4 Apr 13 17:15:49 I didn't saw the UART boot method before Apr 13 17:16:01 I will try this one and if it works try to update my u-boot Apr 13 17:16:03 ok, will check SATA that tomorrow Apr 13 17:16:33 It might be that You have hardware failure Apr 13 17:16:57 tmn505: yes that could also be the reason Apr 13 17:17:39 there are rather many reports about failing ebins Apr 13 17:17:49 check armbian forums Apr 13 17:17:59 tmn505: yes I saw this one: https://forum.armbian.com/topic/9778-espressobin-hang-after-one-day/ Apr 13 17:18:04 this was also one of my errors Apr 13 17:18:20 even Netgate which has sg-1100 Apr 13 17:18:41 have problems with it, it's based on ebin v7 Apr 13 17:19:18 my first board also failed after half year with RAM training Apr 13 17:19:52 tmn505: yes this looks to me like a RAM problem Apr 13 17:19:58 everyone who tried to contact them heard nothing but silence Apr 13 17:20:48 meant Globalscale Apr 13 17:23:17 Hauke: btw, armbian also provides U-Boot images: https://dl.armbian.com/espressobin/u-boot/ Apr 13 17:24:01 yes I saw them Apr 13 17:24:18 I will try to get the UART thing bootinga nd if that works do the update Apr 13 17:24:32 good luck Apr 13 17:25:08 It also looks bad for Marvell that the espressobins are failing Apr 13 17:25:17 for me this looks like a reference board Apr 13 17:26:12 It looks like one, but Globalscale was responsible for manufacturing and probably selecting all the smd components Apr 13 17:26:16 at least Marvell and Globalscale cooperated on this one Apr 13 17:26:59 ok Apr 13 17:27:28 maybe someone from Sartura has more info on that Apr 13 17:27:56 seems like they were responsible to bring up OpenWrt on ebin Apr 13 17:28:14 probably only with an NDA Apr 13 17:28:20 this information Apr 13 17:28:44 everywhere NDA walls Apr 13 17:28:48 I assume Marvell was doing the SW and the schematics and Globalscale the manufacturing Apr 13 17:29:00 yeah Apr 13 17:29:19 which I think is a nice setup Apr 13 17:29:33 to get a cheap reference board with a new chip out Apr 13 17:30:15 it is, but at least the could be more open about failing batches/components Apr 13 17:30:29 it wouldn't leave bad aftertaste Apr 13 17:32:32 yes, but you do not talk about bugs in this industry, only only with an NDA ;-) Apr 13 17:33:22 * tmn505 curses on NDAs Apr 13 17:33:27 as this board was the first one normally avaliable with this chip before the normal mass production started I think it is normal that there are bugs in the hardware Apr 13 17:36:39 yeah, but would be nice if those would be shared with everyone like SolidRun does, at least part of them Apr 13 17:37:19 when passive components are involved, like capacitors Apr 13 17:38:20 failing, or useless resistor in the circuit, causing RTC not to work Apr 13 17:40:24 anyway, seems like Marvell ditched embedded procesors, so no new low end Armadas Apr 13 17:43:16 mhh what else can i do to identify gpio for led and switched if the oem firmware doesn't have the corresponding /sys/class files? Apr 13 17:43:35 I see it has a /sbin/led binary that writes to /dev/armem Apr 13 17:47:28 aldoaldo: what SoC Apr 13 17:56:34 gch981213: buld fails with Makefile:203: *** Missing Build/loader-kernel. Stop. Apr 13 17:56:53 laoder-kernel is not defined for ramips even though it seems to be used for mikrotik? Apr 13 17:57:46 https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/image/Makefile#L77 Apr 13 17:57:50 loader-kernel is there Apr 13 17:58:35 Rene__: ping Apr 13 18:06:04 blogic: ar9330 Apr 13 18:06:13 but it's on a custom pcb Apr 13 18:08:11 aldoaldo: https://openwrt.org/docs/techref/hardware/port.gpio#finding_gpio_pins_on_the_pcb and https://openwrt.org/docs/guide-developer/add.new.device#gpios Apr 13 18:08:27 aldoaldo: so just boot initramfs and brute-force Apr 13 18:17:22 I posted a patch to fix VLAN on MT7530 DSA Apr 13 18:29:57 tmn505: the UART recovery works Apr 13 18:30:19 ohhh, vlan fixes? :D Apr 13 18:30:48 jwh_: to linux netdev mailing list Apr 13 18:31:02 jwh_: then I can backport it Apr 13 18:32:42 ah Apr 13 18:34:01 I wonder if it being vlan unaware is the reason for the weird behaviour I'm seeing Apr 13 18:38:18 Hauke: nice Apr 13 19:07:49 PaulFertser: thw only wayto boot the intrimafs i Apr 13 19:07:54 is via tftp, right? Apr 13 19:07:59 adrianschmutzler: had an old tree checked out - definitely not my day Apr 13 19:08:08 gch981213: your proposed change seems to work Apr 13 19:09:30 https://paste.tecff.de/?6a3d274f58c6ef1c#nQXiVsUxdFlg2D0tDKlySQa+cYbY89/4rajjBPpulgE= Apr 13 19:09:56 Shall i push this fix standalone or do you prepare a fix for all affected boards? Apr 13 19:10:15 i think it's fair to assume every nand board is affected here Apr 13 19:11:12 aldoaldo: any way you can transfer a binary to the target. "loady" in uboot supports ymodem download via serial. But it's slow. Apr 13 19:11:32 aldoaldo: is tftp problematic with this bootloader? Apr 13 19:13:44 i haven't tried yet honestly, it indeed does seems a bit buggy all around Apr 13 19:14:10 for example, if i set something with setenv, then should i see my change with printenv (in the same session)? Apr 13 19:14:45 aldoaldo: yes Apr 13 19:14:53 well i don't Apr 13 19:15:14 i believe in this specific case printenv always prints the values in the flash Apr 13 19:16:14 but i still thinks setenv is working Apr 13 19:16:56 it also has a strange "padfix - fixed uboot bug" listen in the help message Apr 13 19:20:43 i'll give tftp a shot but probably i'll try directly flashing tomorrow Apr 13 19:20:59 tmn505: it does not crash any more after updating the boot loader Apr 13 19:21:27 aldoaldo: how do you plan to get data for flashing to the device? Apr 13 19:21:59 tmn505: it booted up 3 times in a row Apr 13 19:25:07 PaulFertser: i'll flash via a soic clip Apr 13 19:25:52 i think i can cat uboot, uboot-env, myopenwrt image and art in a single bin Apr 13 19:26:00 and write it via flashrom Apr 13 19:26:01 aldoaldo: that's ok but suboptimal for the other users who might want to upgrade this device because most people don't have hardware that writes to flash directly. Apr 13 19:26:38 tmn505: /sys/kernel/debug/clk/clk_summary shows a different CPU clock Apr 13 19:28:13 PaulFertser: you're right Apr 13 19:42:19 dengqf6: yes I saw your patch in the mail, thanks! Apr 13 20:05:13 stintel: hmm, kernel 4.1.51 for ipq807x is weird/ interesting, normally I'd have expected to see Linux 4.4.60 #1 SMP PREEMPT Thu Feb 20 19:27:32 PST 2020 GNU/Linux at least for ipq8074 v1 and v2, is it at least running an aarch64 userland? Apr 13 20:06:51 pkgadd: I have no idea Apr 13 20:08:48 no ssh/ telnet accessibility? Apr 13 20:10:24 pkgadd: it's huawei shell Apr 13 20:10:31 s/shell/cli/ Apr 13 20:11:04 didn't pay much attention to it yet, still configuring the switch Apr 13 20:11:21 and fighting with bird that does not want to redistribute the default route from the kernel protocol to OSPF Apr 13 20:11:50 hehe, o.k. - I'm still shocked how fast 802.11ax can go Apr 13 20:12:33 I have no 802.11ax clients yet :P Apr 13 20:13:35 Intel ax200 is relatively cheap, <20 EUR for M.2 cards, ~25-35 EUR for desktop PCIe Apr 13 20:13:43 only 2 chains though Apr 13 20:14:51 and of course all the Intel limitations, such as no-ir on 5 GHz and firmware oddities Apr 13 20:15:01 but good enough for a client Apr 13 20:15:02 yeah I was considering it for my xps13 but that thing is so old and broken Apr 13 20:15:17 I might wait until the T14s are finally available Apr 13 20:16:22 grrr that damn bird wtf Apr 13 20:17:45 Hauke: this is my output: http://ix.io/2hV0 Apr 13 20:18:35 Hauke: that's on kernel 5.6.3, was testing aardvark patches for Pali Rohar Apr 13 20:19:26 tmn505: with the old U-Boot cpu was at 200000000, but the new one it is at 500000000 Apr 13 20:19:58 and I do not get this any more: "advk-pcie d0070000.pcie: config read/write timed out" Apr 13 20:20:01 I never tried CPIe Apr 13 20:20:03 *PCIe Apr 13 20:20:36 that was fixed in 5.4 Apr 13 20:20:39 but good that it is working now stable Apr 13 20:20:46 btw for people with older laptops, you can use ax200 refits Apr 13 20:21:02 ax200 m.2 1216 refitted to mini pcie Apr 13 20:21:04 tmn505: I used the same kernel, I did not change the SD card content between the update Apr 13 20:21:17 "AX200HMW" Apr 13 20:21:17 both with 5.4 Apr 13 20:22:38 that's good, it works stable on my end, wtih all miniPCIe cards that i have Apr 13 20:22:40 tmn505: I am now using U-Boot 2017.03-armada-17.10.1-gaee49fc Apr 13 20:22:56 mines the same Apr 13 20:23:39 gweentea: nice, I didn't know about those yet Apr 13 20:24:10 Hauke: if I ever get motivation, I'll send patch to update U-Boot for ebin Apr 13 20:24:41 pkgadd: have you seen the aliexpress listing, they are fitting 1216's in ;) Apr 13 20:25:39 gweentea: I was first looking at ebay, but now I do, yes Apr 13 20:26:02 pkgadd: be wary on some tho Apr 13 20:26:03 https://www.reddit.com/r/thinkpad/comments/f55d7y/dont_buy_the_ax200_mpcie_from_aliexpress/ Apr 13 20:26:16 you might need to remove the lid and check Apr 13 20:26:34 some only has 1x antenna connected Apr 13 20:26:41 hehe, yeah - I got myself a desktop PCIe card first Apr 13 20:26:41 anyway, thats all Apr 13 20:28:58 adrianschmutzler: is your ath25 patch series in a staging tree? i can test. Apr 13 20:29:13 luci-ssl-openssl failed to come up, luci-ssl is fine, 19.07.2 Apr 13 20:29:22 archer A7 v5 Apr 13 20:56:57 is there a way to cleanly disable library chosen by other apps after those apps are de-selected? Apr 13 21:07:10 not that I've found. Apr 13 21:12:47 russell--: my staging tree, branch ath25final Apr 13 21:13:34 but I have almost no kernel experience, so expect it to fail. I just made it compile Apr 13 21:13:52 https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/ath25final Apr 13 21:24:04 adrianschmutzler: understood Apr 13 21:24:07 thanks! Apr 13 21:35:32 too many package conflicts, nginx-mod-luci wants to install... provided by nginx-mod-luci-ssl Apr 13 21:43:13 rr123: if you wnat to do funky stuff with replacing some common cores, you might be better off starting with a stub and expanding with make defconfig, Apr 13 21:43:24 it gets a bit crazy trying to select/deselect things in the right order sometimes Apr 13 21:44:27 will do, thanks. the real thing bothers me is the new luci somehow is lagging Apr 13 21:58:04 ldir: * check_data_file_clashes: Package kmod-sched wants to install file /home/stijn/Development/LEDE/source/build_dir/target-x86_64_musl/root-x86/lib/modules/5.4.31/act_police.ko Apr 13 21:58:05 But that file is already provided by package * kmod-sched-police Apr 13 21:59:50 ok, something for tomorrow Apr 13 22:02:10 When building a squashfs image, should i expect it to be the exact size that it is specified in IMAGE_SIZE := 8000k in Config.mk? Apr 13 22:02:30 Or just for it to be smaller? And if yes what should i do with the remaining space? pad it with zeroes? Apr 13 22:03:51 aldoaldo: that stated size is the maximum limit, it must be smaller. in case of factory images it *might* be padded to that size (in order for the OEM updater to accept it), but not necessarily Apr 13 22:04:45 Specifically, i changed the factory layout in order to gain more space. The original layout had two rootfs, one for recovery i blieve Apr 13 22:05:08 So now i have a 4MB image to fit in an 8M mtd partition. Will openwrt automatically detect the free space? Apr 13 22:18:03 hm, octeon doesn't use dts from the kernel tree right? Apr 13 22:18:12 or am I confused Apr 13 22:57:57 tried procd+zram and now I can never sysupgrade? Apr 13 22:58:19 even using the standard release sysupgrade.bin does not help. Apr 14 01:08:36 ok I have not seen this for years, can't upgrade archer-A7 via sysupgrade, tried put sysupgrade.bin under /tmp/shm, /tmp, tried failsafe, tried tftp-boot, it refuses to upgrade Apr 14 01:08:53 I don't know what went wrong but it was upgrading just fine before noon Apr 14 01:09:38 the only thing is that I wrongly tried procd+zram which gave me a small /tmp that can't hold sysupgrade.bin anymore(flash has no space), but I since downsized my sysupgrade.bin to fit there Apr 14 01:10:04 4 hours wasted , sigh Apr 14 01:22:15 finallOM Apr 14 01:23:04 finally tftp saved it Apr 14 02:07:27 anyone know how to get the difference in commits between a tag and a branch? Apr 14 02:09:51 git diff tag branch? Apr 14 02:15:37 sysupgrade because for whatever reason I deselect mtd :( now it works Apr 14 02:27:17 nginx-luci-ssl conflicts with nginx-luci(can only chose one?), neither selects nginx which is strange Apr 14 02:46:12 daemon.info procd: Instance nginx::instance1 s in a crash loop 7 crashes, 0 seconds since last crash **** ENDING LOGGING AT Tue Apr 14 02:59:57 2020