**** BEGIN LOGGING AT Sun Sep 01 02:59:57 2019 Sep 01 08:53:45 Hi! I'm working on BPI-R2 improvements. I have a script which creates SD image file. After fresh image is booted jffs2 refuses to mount because "no jffs2 nodes are found" and I have to run jffs2reset to initialize the fs. How would I do that in the script instead? How do other devices solve this problem? Sep 01 08:53:54 Script w. comments: https://github.com/openwrt/openwrt/pull/1135/files/d9774e4a605c4bef9d901aab771ea083b8eab3e7..71789193660badea92581552b142a9185f68f05d#diff-695ee32952f12b7b5a0256f6ff429177 Sep 01 09:12:22 aparcar[m]: let me look at it Sep 01 09:40:18 aparcar[m]: so i guess this patch is expected to change: Sep 01 09:40:19 openwrt-bcm53xx-smartrg-sr400ac-squashfs.trx Sep 01 09:40:27 to include generic, so: Sep 01 09:40:31 openwrt-bcm53xx-generic-smartrg-sr400ac-squashfs.trx Sep 01 09:40:34 is that correct? Sep 01 09:40:41 looks OK to me I think, Hauke? Sep 01 09:41:06 I am also fine with it Sep 01 09:41:29 but this is a generalc hange that we always will have a subtarget even when there is only one Sep 01 09:44:02 rmilecki: correct Sep 01 09:44:18 Hauke: does it annoy you? from my point of view it just makes things more unified Sep 01 09:44:38 Hauke: it's also true that we already were using "generic" directory Sep 01 09:44:51 even without this patch it's bin/targets/bcm53xx/generic/ Sep 01 09:46:12 ok Sep 01 09:46:20 I haven't noticed that Sep 01 09:46:26 I am fine with these two patches Sep 01 09:47:00 great thank you! Sep 01 10:00:52 another question: https://github.com/openwrt/openwrt/pull/1135/files/5b17a456a1b201bd8d9a825fa283bfa1bfa31dd5..d9774e4a605c4bef9d901aab771ea083b8eab3e7#r207864390 how does one patch the dts file directly? Sep 01 10:11:58 abbradar: my guess is that blogic thought mt7623n-bananapi-bpi-r2.dts is in target/ Sep 01 10:13:28 rmilecki: ah, you mean separately from the kernel tree? it's not now but should I put it there pre-patched instead? Sep 01 10:13:38 (not sure how it's done usually in openwrt) Sep 01 10:14:32 abbradar: i just replied Sep 01 10:14:36 "mt7623n-bananapi-bpi-r2.dts is upstream DTS file, if there is something wrong in it, please send upstream patch for that" Sep 01 10:15:46 I see, thanks. The patches are from the bpi-r2 developer themselves, not sure why didn't they upstream it. I'll try at least Sep 01 10:16:05 you can ping them Sep 01 10:16:21 we just don't want such random patches floating all around Sep 01 10:16:31 it's much cleaner & easier for maintenance to have original .dts fixes Sep 01 10:16:34 *fixed Sep 01 10:17:41 sure, let's try. the developers ignore all attempts to upstream their work, so I'll try to send it by myself too if I get no reply Sep 01 10:18:48 really? Sep 01 10:18:49 uh :( Sep 01 10:19:11 they have their own fork of LEDE (!) with patches on top Sep 01 10:19:31 just great... Sep 01 10:20:14 sounds like hardware you want to use... not. Sep 01 10:21:03 it's a chinese "router development board" so I half-expected things to be this way. wifi support is broken completely too (see the original PR), but I want to upstream to openwrt at least some patches to get most of hardware working Sep 01 10:21:15 f00b4r0: I chose it for pcie slot back in the day ;_; Sep 01 10:21:34 heh Sep 01 10:38:17 I'm asking the developers about patches. Should I leave them in the PR for now or don't submit them to openwrt until they are somehow upstream? Sep 01 10:56:00 rmilecki: huh, it seems I was stupid and they actually did upstream their changes, so current linux master has these changes. what should I try in this case? just taking .dts file from master won't work, would it? Sep 01 10:56:21 abbradar: please backport upstream patch Sep 01 10:56:49 abbradar: use "git format-patch -1 SHA-SUM-HERE" and move resulting file into openwrt patches-4.19 dir in mediatek target Sep 01 10:57:04 abbradar: adjust prefix of that patch Sep 01 10:57:22 abbradar: and maybe do "make target/linux/refresh V=s" to make sure it applied cleanly Sep 01 10:57:45 rmilecki: I see, thanks. let's see what happens... Sep 01 10:57:54 then send a patch / pull request to OpenWrt with something like "mediatek: backport upstream DTS fix for pinctrl" or whatever that patch is about Sep 01 10:58:53 I already have https://github.com/openwrt/openwrt/pull/2365 , should I just force-push there or open separate PRs? Sep 01 11:17:26 jow: what is missing for a 19.07-rc1? Sep 01 11:17:34 how can I help Sep 01 11:18:15 abbradar: force push is fine & better Sep 01 11:18:23 just make sure you keep clean commits there Sep 01 11:19:02 ok, backporting now (fun fact: upstream patches are completely different from what board devs themselves have in their LEDE fork). thank you for all the help! Sep 01 11:19:27 abbradar: You can try to build a u-boot package using upstream u-boot instead. Sep 01 11:20:07 abbradar: Mediatek submitted mt7623 support to upstream u-boot several months ago with support for bpi-r2. Sep 01 11:20:26 gch981213: aha, I see - I'll try that now Sep 01 11:22:45 abbradar: maybe they have to revise they patches after upstream review Sep 01 11:23:04 I guess so Sep 01 11:23:22 I'd just expect them to update them in their fork too after that... Sep 01 11:38:18 abbradar: true Sep 01 11:38:43 "no mr. Bond, I expect you to die" Sep 01 11:40:54 rmilecki: I remember now why didn't I just `git format-patch` a year ago - we have `patches-4.14/0064-dts.patch` which has some version of the dts already in place, seems the same one devs have in their fork Sep 01 11:41:16 so basically my patches are backported patches from upstream on top of that .dts Sep 01 11:42:29 guess I should just leave them like that then?... I could also rename them to proper commits from the tree but they are different in some places, it's not a clear backport Sep 01 11:44:46 abbradar: uh :( Sep 01 11:45:10 abbradar: i'd say: backport your patch, and use some low prefix like 000x or whatever lower than 0064 Sep 01 11:45:17 abbradar: upstream patches should be first, really Sep 01 11:45:30 abbradar: then rebase/update that ugly 0064-dts.patch Sep 01 11:46:06 rmilecki: hm, let's try that, hope it's not too messy Sep 01 11:47:10 is there some tool for mass-renaming patch numbers, say move all >=0064 to 0100? Sep 01 11:56:44 abbradar: i don't know about the tool, but the openwrt patch numbering follows a certain format (which i cannot find atm) Sep 01 11:57:14 well it does for the kernel patches, don't know if it does for other packages (devs will know better) Sep 01 12:05:09 Borromini: I see, thanks. I'll try to find something in docs Sep 01 13:24:42 abbradar: BTW I think the vendor's approach for the sd/emmc image is ugly. I'd prefer setting up an actual partition table on sd card and use f2fs overlay instead. There should be some targets already using it but I can't find it now, sorry. Sep 01 13:25:57 gch981213: sounds good, I wasn't actually sure how to make openwrt use a partition table so I just ported over what vendor does. I guess I'll search around once more, at least x86 should use this Sep 01 13:29:52 abbradar: i'm not aware of such a tool Sep 01 13:29:55 abbradar: also see target/linux/generic/PATCHES Sep 01 13:30:16 rmilecki: I just wrote one by myself :D Sep 01 13:30:33 I managed to compile it, ugly dts patch isn't needed anymore. Will try it later Sep 01 13:57:03 abbradar: the mediatek target should anyway be switched to kernel 4.19 soon Sep 01 13:57:14 I think it is sufficent if you add your cahnges for kernel 4.19 Sep 01 13:57:20 *changes Sep 01 13:58:36 Hauke: yeah, planned to do that - I stay on 4.14 now because of shitty out-of-tree wifi drivers but someone already ported them Sep 01 13:59:17 abbradar: which wifi driver are you using? Sep 01 14:00:14 Hauke: mt6625l. vendor came up with an abomination which uses Android drivers, see https://github.com/openwrt/openwrt/pull/1135 Sep 01 14:05:09 I have my own fork of them which works with our backported driver but it still requires some in-kernel patches: https://github.com/abbradar/mt6625l-wlan-gen2 Sep 01 14:05:32 backported wireless layer* Sep 01 14:06:24 abbradar: thanks Sep 01 14:07:01 mt6625l looks more like an analoge frontend Sep 01 14:15:07 Hauke: what do you mean? Sep 01 14:42:23 is there a standard way to modify usptream DTS, like overlays? Sep 01 14:42:31 or should i patch the kernel dts Sep 01 14:45:10 aep: patch the kernel dts Sep 01 14:49:22 aye Sep 01 14:53:15 btw what can i do about not having sysupgrade files? this is sunxi/orangepi-zero Sep 01 14:53:35 its apparantly just using a rw ext4 Sep 01 15:12:15 rmilecki: Sadly with upstream .dts patches it doesn't boot at all with no printk messages. I ran diffs against several kernel versions and my current theory is that upstream .dts also needs some non-dts patches, but I have no idea how to find them. I don't know how to connect a debugger to this board so my options basically ran out. Any ideas? Sep 01 15:37:11 abbradar: which board? Sep 01 15:37:33 aep: bananapi bpi-r2 Sep 01 15:37:42 trying to upstream openwrt support for it Sep 01 15:37:53 nice Sep 01 15:38:13 and by debugger you dont mean tty i guess Sep 01 15:38:21 because that would be easy :D Sep 01 15:38:25 aep: yeah, I'd like JTAG or DAP or smth Sep 01 15:38:39 i dont think they expose them Sep 01 15:38:41 UART is radio silent with upstream .dts Sep 01 15:38:47 aep: ;_; Sep 01 15:39:09 doesnt this thing have uboot? Sep 01 15:39:25 it works actually and boots with vendor patches Sep 01 15:39:32 and yeah, it has u-boot Sep 01 15:40:04 I'd like to find out what goes wrong when I boot with upstream .dts (from newer kernel) instead of old vendor one Sep 01 15:40:27 its an h2+ isnt it? Sep 01 15:40:36 did you try booting a different board image Sep 01 15:40:54 also #linux-sunxi knows stuff about upstream Sep 01 15:41:40 aep: It's a mt7623n board Sep 01 15:41:53 oooh Sep 01 15:41:54 aep: mt7623n yeah Sep 01 15:42:32 never mind then, confused it with a different banana board. Sep 01 15:42:42 there's actually someone who ports vendor patches from newer kernels and it seems 5.1 works ootb Sep 01 15:43:02 yeah i have the previous version, it has an a20 Sep 01 15:43:24 so I'm leaning towards just leaving current patches as they are till we get a newer kernel somewhere in the future Sep 01 15:43:26 abbradar: You could just backport necessary commits instead of grabbing all changes from upstream Sep 01 15:43:50 gch981213: already done, yeah. idea was to be as close to upstream as possible Sep 01 15:44:15 but I'll just leave my old minimal changes instead Sep 01 15:47:21 ok, i fixed my issue. how does openwrt feel about enabling non-exposed peripherals on boards? upstream apparantly has usb disabled because its on pin headers instead of standard usb plug Sep 01 15:47:39 i guess we dont enable those either because consumer? Sep 01 15:49:01 how can i be lost if i got nowhere to go Sep 01 15:49:03 aep: from what i gathered if there are headers and you need to solder stuff on, it's not ready to use and as such not enabled in the dts Sep 01 15:49:55 well grey zone sort of. there's shields and those dont work with openwrt Sep 01 15:56:18 I have a bootloader package which has Build/InstallDev section where it copies itself to staging_dir and image building scripts use it later. How do I make a platform unconditionally depend on it? Maybe there's more graceful way? Sep 01 16:05:43 abbradar: It seems that a standard u-boot package already do that. Sep 01 16:06:13 gch981213: nah, not u-boot, there's also board-specific stage-0 bootloader which I need to have in staging-dir Sep 01 16:06:24 vendor provides it in their u-boot tree but I want to split them to use upstream u-boot Sep 01 16:11:09 Ah, you mean that preloader. I'll throw those binary blobs into target/linux/mediatek/image directly. Sep 01 16:12:49 gch981213: true Sep 01 16:13:04 abbradar: wait... That may be a bad idea. Sep 01 16:16:11 I don't see any similar files in tree Sep 01 16:16:47 ah, there's smth in at79/image/bin Sep 01 16:17:05 abbradar: an empty package seems overkill to me. Last time when I have a fixed binary blob to be part of the image I put it in target/linux/ath79/image/bin Sep 01 16:17:37 yeah, I think it's simpler that way too Sep 01 16:17:54 let me do this and see if maintainers complain Sep 01 16:36:56 can someone explain to me how command line arguments in u-boot work? how would I specify default command line arguments? should I use u-boot at all, or e.g. CONFIG_CMDLINE? Sep 01 16:37:28 vendor specifies cmdargs in u-boot and then overrides via .dts :D Sep 01 16:48:20 abbradar: mark it hidden (HIDDEN:=1) and let it default to y if the target is selected, some of the u-boots do that Sep 01 16:50:21 KanjiMonster: cool, didn't know about HIDDEN Sep 01 16:55:22 gch981213: tried upstream u-boot (2017.07), it requires python and swig now :( I'll stick with vendor u-boot for now, or maybe there's a simple way to add them? Sep 01 17:07:20 I use HIDDEN now and u-boot just doesn't build, as if it's not selected by default. I set BUILD_DEVICES to the right device; do I need anything else for it to work? Sep 01 17:11:37 a-ha, after reading Makefile macro magic it seems that I needed to specify BUILD_TARGET in U-Boot/Default, not in U-Boot/$(DEVICE), for it to work Sep 01 17:29:59 thank you all for your help! I think my patches are ready for review: https://github.com/openwrt/openwrt/pull/2365 Sep 01 18:52:27 Hauke Plesse don't forget to merge the generic patches Sep 01 19:02:10 abbradar: well, keep digging, you surely have a working .dts and broken dts. Compare them and apply change by change until you get a working console or sth Sep 01 20:19:40 rmilecki: I'm just not sure that's a good idea, we'll need to understand why the result works too - current patches are much simpler in that regard Sep 01 20:34:33 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Sep 01 20:35:08 is rpcd installed by default or only when luci etc is installed? Sep 01 20:36:50 aparcar[m]: not by default i tihnk Sep 01 20:39:26 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=include/target.mk;h=a813ba2d2d87de82b5c9762e8d6000ce424edba2;hb=HEAD#l16 - DEFAULT_PACKAGES, no rpcd Sep 01 20:42:07 rmilecki: thank you Sep 01 20:42:30 swalker: and thank you :) Sep 01 21:28:06 swalker: i got notified for patch CVEs that i think (without checking) are already fixed Sep 01 21:38:09 russell--: the CVE ID isn't in the patch name or referenced in the patch file is why Sep 01 21:43:17 same commit but 2 separate CVEs, lovely Sep 01 21:43:57 https://nvd.nist.gov/vuln/detail/CVE-2018-20969 - ... NOTE: this is the same commit as for CVE-2019-13638, but the ! syntax is specific to ed, and is unrelated to a shell metacharacter. Sep 01 21:45:16 swalker: am i doing it wrong? devel/patch/patches/060-CVE-2019-13638.patch Sep 01 21:46:32 russell--: are you talking about master or 18.06? Sep 01 21:47:16 that's master Sep 01 21:47:24 master is because CVE-2018-20969 isn't referenced, 18.06 isn't patched Sep 01 21:51:28 the email i got has "master" in the subject Sep 01 21:52:53 renaming 060-CVE-2019-13638.patch to 060-CVE-2018-20969-CVE-2019-13638.patch would be the simple fix Sep 01 21:55:52 it's just looking for that string CVE-$year-$serialno ? Sep 01 21:56:36 yes, either in the patch name or in the patch itself Sep 01 21:57:02 historically the patch name was the preferred method Sep 01 21:57:03 (I'll ask here since there was activity, and is likely on topic) I have some patches I want to contribute to the openwrt make_ext4fs fork; I'm not sure about the quality of the implementation, is there a process to get a review from contributors other than posting to the mailing lists? Sep 01 21:58:03 swalker: the email also lists CVE-2019-13636, which is also patched in master: devel/patch/patches/050-CVE-2019-13636.patch Sep 01 21:59:36 (i'm referring to the packages feed here) Sep 01 22:02:12 russell--: the emails I have list 1 CVE (CVE-2018-20969) for master and 3 (CVE-2018-20969, CVE-2019-13636, CVE-2019-13638) for 18.06 Sep 01 22:10:08 swalker: in gmail, they are threaded together under one subject line afaict, but looking closer, the subject line is different (18.06) for the three CVE email. thanks for the explanation. Sep 01 22:12:15 yep Sep 01 22:14:16 there would've been a 3rd email for the 3 19.07 patch CVEs but those emails are disabled for now Sep 01 22:33:51 i don't have the ability to cherry-pick into the 18.06 branch, fwiw Sep 01 22:41:06 would be happy to get some comments on my proof of concept here https://github.com/openwrt/openwrt/pull/2366 Sep 02 00:01:01 russell--: pull request Sep 02 02:03:27 abbradar: It seems that you could patch binman away like this: https://paste.ubuntu.com/p/JzVYJPSWWn/ It's only needed for MT7629. Sep 02 02:47:30 good morning **** ENDING LOGGING AT Mon Sep 02 02:59:56 2019