**** BEGIN LOGGING AT Mon Feb 03 03:00:39 2020
Feb 03 09:42:25 <Pepe> Guys, procd works for you in 18.06.7? I can not start via procd, for example, transmission. I think there is something broken due to ubus/libubox backport. In 19.07, I don't have such issues anymore.
Feb 03 11:39:18 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Feb 03 12:51:41 <urjaman> Hiya, i have a device tree for the TP-LINK WA850RE v4 - still a bit to be cleaned but boots from TFTP fine and LEDs, buttons, MAC addresses and the wmac "eeprom"(mtd location) work
Feb 03 12:52:43 <urjaman> https://github.com/urjaman/openwrt/commit/cf4e484553f21b091cf54e8bed714f12cf90633e looks like this now for reference
Feb 03 12:53:09 <urjaman> and yeah it's a ridiculously difficult to open "4/32" device but i play with what i have around
Feb 03 12:55:05 <urjaman> anyways i have a few questions? 1. i assume i should use the same LED names as the ath79 v2 of the 850RE? (i kinda accidentally forgot to look at that and named them based on other MT7628 device trees)
Feb 03 12:57:02 <urjaman> like tp-link:blue:lan vs tl-wa850re-v4:blue:lan? (also some device used rssi* for signal bars so i have rssi1 to 5 but the v2 has signal1 to 5...)
Feb 03 13:09:41 <urjaman> also maybe slightly more importantly i have some sort of issue (maybe PEBCAK but still) with the image generation... like if i pick only the squashfs as the output image for the WA850RE, nothing is generated (it doesnt even try making the factory/sysupgrade binaries)
Feb 03 13:10:16 <urjaman> but if i just pick all of them it does try it, didnt go testing one by one which one it needs but like i'd expect squashfs to be all that they depend on
Feb 03 13:24:19 <adrianschmutzler> urjaman: In ramips it is common to use the model part of the device name for the leds, so no tplink
Feb 03 13:24:30 <adrianschmutzler> have a look at e.g. rexxx devices
Feb 03 13:33:20 <urjaman> okay so my current led names are fine for that part atleast
Feb 03 13:33:38 <urjaman> maybe "re" instead of RE" tho... any preference on rssiN vs signalN?
Feb 03 13:47:34 <adrianschmutzler> your current names look correct
Feb 03 13:48:03 <adrianschmutzler> there are several small formal things, but in general the commit looks okay
Feb 03 13:49:42 <urjaman> yeah i still need to build an image that is small enough to flash on the thing and get a test of it booting openwrt from flash
Feb 03 13:49:47 <adrianschmutzler> I would also still be willing to merge a 4/32 device into trunk if it's working properly (at least in this case, where no special work has to be done), so feel free to submit that as a PR
Feb 03 13:50:19 <adrianschmutzler> urjaman: I'd expect that with standard buildbot settings (no luci) this should run
Feb 03 13:51:13 <urjaman> standard settings made me an image that some tool when making the squashfs-based image claimed to be like 600k too big
Feb 03 13:51:15 <adrianschmutzler> The wa850re v2 I added to ath79 had less flash IIRC, but I do not know how different ramips and ath79 are in that aspect (size).
Feb 03 13:52:19 <urjaman> i think my new attempt actually made a squashfs-based image but it is 3840k and i actually only have 3712k firmware partition on it (i think the mktplinkfw partitioning preset 4Mlzma is bigger than this thing has...)
Feb 03 13:52:24 <adrianschmutzler> are you using the correct flash layout? 4Mlzma vs. 4Mmtk?
Feb 03 13:52:42 <urjaman> the tplink-v1 doesnt know of 4Mmtk
Feb 03 13:52:56 <adrianschmutzler> ah, I see
Feb 03 13:53:23 <urjaman> i just picked something where the beginning addresses looked similar to what the stock fw has
Feb 03 13:54:28 <urjaman> I'm not familiar with this tplink stuff so I was just picking something that might be close enough and seeing what happens
Feb 03 13:55:45 <urjaman> btw do we have any facility to basically use initramfs+jffs2? (instead of squashfs) ... i guess that would be a bit of a hassle to setup and bad for RAM but the initramfs compresses way better and i do have enough RAM to hold a basic routing setup in it
Feb 03 13:55:58 <adrianschmutzler> Well, one problem is also that mt76x8 does not have small_flash set
Feb 03 13:56:22 <adrianschmutzler> no idea about that last one
Feb 03 13:56:59 <adrianschmutzler> but just by replacing wpad-basic with wpad-mini you should get 100kiB
Feb 03 13:57:29 <urjaman> ok i'll look at that
Feb 03 13:57:49 <urjaman> (i mean just to test booting i can get rid of AP mode or something to get enough space)
Feb 03 13:57:51 <adrianschmutzler> DEVICE_PACKAGES := -wpad-basic wpad-mini
Feb 03 13:58:12 <adrianschmutzler> sadly, one of the most powerful things is to disable ipv6
Feb 03 13:58:42 <adrianschmutzler> it's under "global build settings"
Feb 03 13:59:40 <urjaman> i'm not new to making tiny images (i have a W268R with 2M flash and 16M ram running a very very tinyfied and patched 19.07 :P) but it'd be nice if the build defaults made a bootable image
Feb 03 13:59:43 <adrianschmutzler> and if you build something else in between, it is typically helpful to do a "make clean" in between, as some packages get bigger in some cases
Feb 03 14:00:06 <adrianschmutzler> yes, if not, it won't be merged
Feb 03 14:01:08 <adrianschmutzler> I'll give it a try myself
Feb 03 14:27:39 <urjaman> ah duh, the -factory.bin is padded to 3840k because that's the flash size the tool expects
Feb 03 14:29:36 <urjaman> 0x de ad c0 de (i think that's the marker for the beginning of the JFFS2 area with the split-y thing) is at 0x2e9000 with my current firmware (not defaults but hey atleast i did get it small enough... just need to add a preset i can use to mktplinkfw )
Feb 03 14:35:38 <adrianschmutzler> I just built with your patch and -wpad-basic wpad-mini and I get images out of the box.
Feb 03 14:35:51 <urjaman> cool
Feb 03 14:37:39 <adrianschmutzler> so, just try "rm .config", "rm -rf tmp", select your device in make menuconfig, run "make clean" and then "make ..."
Feb 03 14:38:40 <adrianschmutzler> in that order, and take care you select rootfs_per_target in make menuconfig
Feb 03 14:39:21 <urjaman> where is that knob? i remember seeing it when reading the image.mk file but not in menuconfig
Feb 03 14:39:33 <urjaman> (seeing lots of references to it that is)
Feb 03 14:40:21 <adrianschmutzler> have to choose "Multiple devices" in "Target Profile" and the enter "Target Devices". There it's the second from top: "Use a per-device root filesystem ..."
Feb 03 14:40:37 <adrianschmutzler> Without that, your DEVICE_PACKAGES are ignored, I think.
Feb 03 14:40:44 <urjaman> Ah okay
Feb 03 14:40:55 <urjaman> i just picked my device directly
Feb 03 14:40:57 <adrianschmutzler> And then select your device via "Target Devices"
Feb 03 14:41:12 <urjaman> (not the "multiple devices" thing)
Feb 03 14:41:26 <adrianschmutzler> From my experience, always use "Multiple devices", even if you have only one device.
Feb 03 14:41:36 <urjaman> that makes very little sense :D
Feb 03 14:41:46 <adrianschmutzler> and then rootfs and your devices
Feb 03 14:42:00 <adrianschmutzler> that will produce the same as what the build bot does
Feb 03 14:42:28 <urjaman> or i mean maybe the configuration should be made to infer "Multiple devices with one device selected" when you just pick one device then if that's how the build is supposed to be done
Feb 03 14:42:49 <adrianschmutzler> I'm actually not sure what happens when you select your device directly, but since my way works, I have never tried to find
Feb 03 14:43:59 <adrianschmutzler> I'm not an expert with this stuff, maybe it doesn't matter at all and you just had some remainder of an earlier build somewhere, inflating some packages
Feb 03 14:45:53 <urjaman> that's certainly possible, my config was kinda messy since i first used some other MT76x8 TP-LINK as the target to get the firmware tools built (used those to inspect the vendor fw to come up with the settings)
Feb 03 14:46:43 <adrianschmutzler> I always have this problem when switching from ath79/generic to /tiny, never builds images unless I do "make clean"
Feb 03 14:48:27 <adrianschmutzler> (I've never had time to look for the reason)
Feb 03 14:50:03 <urjaman> I added a preset like 4Mlzma to mktplinkfw that has 0x3a0000 (3712k) as the size (instead of 3840k)
Feb 03 14:50:20 <urjaman> i just used 4Mlzma3712k as the name for my test but are there like rules for these?
Feb 03 14:52:01 <adrianschmutzler> I don't think so. But maybe 4Mmtk is to generic, and we should consider finding a better scheme for both
Feb 03 14:52:06 <adrianschmutzler> to->too
Feb 03 14:52:38 <adrianschmutzler> ah, sorry again, it's v2 ...
Feb 03 14:53:38 <adrianschmutzler> you might actually go for 4Mmtk there.
Feb 03 14:56:33 <adrianschmutzler> yes, the only other tplink-v1 device in ramips (RE200 v1) uses 8Mmtk
Feb 03 14:56:44 <adrianschmutzler> https://github.com/openwrt/openwrt/blob/master/tools/firmware-utils/src/mktplinkfw.c#L148
Feb 03 14:56:53 <urjaman> i think one could actually free a bunch of fw space (like 192k) on this thing but that would involve moving the MAC address somewhere else and also would wipe the tplink fw user settings etc so i guess openwrt doesnt do that kinda stuff
Feb 03 14:56:58 <adrianschmutzler> https://github.com/openwrt/openwrt/commit/a3010a7f8dbe04972efef16ed7d81b5fd72e9a94
Feb 03 14:57:18 <adrianschmutzler> exactly
Feb 03 14:58:19 <adrianschmutzler> In the trunk it should not destroy those partitions.
Feb 03 14:58:41 <adrianschmutzler> you can always have a local modification though
Feb 03 14:59:18 <adrianschmutzler> btw, for me it even builds with wpad-basic
Feb 03 14:59:33 <adrianschmutzler> so just your patch as is
Feb 03 14:59:33 <urjaman> yeah my own plan is to try and put a 16MiB flash chip on this eventually but that isnt very upstreamable either :P
Feb 03 14:59:41 <adrianschmutzler> indeed
Feb 03 15:00:40 <adrianschmutzler> but if you get it working in standard setup, I'd still be willing to merge it in that status, and then other people will have less to do for modifying it
Feb 03 15:01:56 <adrianschmutzler> so, feel free to open a PR, then we can move the discussion there, and I can provide some more detailed comments on your code
Feb 03 15:02:12 <adrianschmutzler> (or via the mailing list, of course)
Feb 03 15:02:40 <adrianschmutzler> I'd still exchange wpad-basic -> wpad-mini though
Feb 03 15:02:55 <urjaman> yeah i put that in already in my tree
Feb 03 15:03:02 <urjaman> (like i did that locally)
Feb 03 15:03:53 <urjaman> i'll make a commit adding 4Mmtk to mktplinkfw (the v1) as a before the WA850RE support and then after i've tested it i'll open a PR
Feb 03 15:03:58 <adrianschmutzler> one other thing might be -uboot-envtools, but I haven't checked whether you need them and whether they are included by default on this subtarget
Feb 03 15:04:40 <adrianschmutzler> sounds good, I will leave some style commit in your current commit for now
Feb 03 15:08:24 <urjaman> currently re-figuring out how to make it spit out the -factory.bin etc ... i'm thinking you need to enable the ext4 image (with it comes the weirdly nondescriptive "Gzip images" or something) and then it tries to make them
Feb 03 15:10:07 <urjaman> (cpio.gz wasnt it, nor was cpio.gz+tar.gz ...)
Feb 03 15:11:09 <adrianschmutzler> squashfs
Feb 03 15:11:18 <urjaman> yeah that one is always enabled
Feb 03 15:11:26 <adrianschmutzler> will be enabled by default if you have deleted .config
Feb 03 15:11:28 <urjaman> if you just enable that and nothing it outputs no images
Feb 03 15:11:40 <adrianschmutzler> that will build you sysupgrade and factory
Feb 03 15:11:42 <urjaman> if you have ramdisk/initramfs enabled it outputs only that
Feb 03 15:11:46 <urjaman> no it doesnt
Feb 03 15:12:11 <adrianschmutzler> I have default: ramdisk and squashfs
Feb 03 15:12:20 <urjaman> yeah with those you only get the initramfs image
Feb 03 15:12:32 <adrianschmutzler> if initramfs is built and squashfs isn't, then your image is too big
Feb 03 15:12:58 <adrianschmutzler> there should be a warning somewhere in your output about that
Feb 03 15:13:49 <urjaman> ah maybe the default build attempts to make them but just ignores the error
Feb 03 15:14:04 <adrianschmutzler> something like that, yes
Feb 03 15:14:07 <urjaman> the error on the ext4 being too big does fail the build and then i see that
Feb 03 15:14:28 <adrianschmutzler> still, with the sequence I provided above it should build
Feb 03 15:14:32 <adrianschmutzler> at least it did for me
Feb 03 15:14:57 <urjaman> but i think this one is from the squashfs factory build (it continued to try and make the ext4): [mktplinkfw] *** error: images are too big by 173561 bytes
Feb 03 15:15:17 <adrianschmutzler> looks like what I'm used to
Feb 03 15:15:39 <urjaman> make[5]: [Makefile:201: /home/urjaman/WA850RE/openwrt/bin/targets/ramips/mt76x8/openwrt-ramips-mt76x8-tplink_tl-wa850re-v4-squashfs-factory.bin] Error 1 (ignored)
Feb 03 15:15:55 <urjaman> like someone is being too ignorey with the make flags
Feb 03 15:16:18 <urjaman> because if you do this with just "make -j6" or whatever the build completes with no error and no detailed output
Feb 03 15:16:38 <adrianschmutzler> yes, might be desired for the buildbot
Feb 03 15:17:11 <adrianschmutzler> don't know why it's behaving like that, but it's the same for me
Feb 03 15:18:41 <urjaman> I'm thinking it should atleast print out the error from mktplinkfw (even in the quiet mode) even if it doesnt fail the whole build
Feb 03 15:18:56 <urjaman> because otherwise you have no idea how much too big it is or even what the problem was
Feb 03 15:19:43 <adrianschmutzler> yes, you might either try to address that or file in a feature request via bugs.openwrt.org
Feb 03 15:20:51 <urjaman> okay it still tried to put in wpad-basic (like full Y or asterisk) but also built wpad-mini (but only as package, M)
Feb 03 15:21:54 <urjaman> i might've messed up that packages selection thingy somehow (also not sure how it works in multiple devices mode ... hey i'm used to only building single device dedicated firmwares, not a distro :P)
Feb 03 15:23:52 <adrianschmutzler> that's a little complicated indeed
Feb 03 15:24:29 <adrianschmutzler> I'd thus recommends to just use the DEVICE_PACKAGES variable in the image makefile for now
Feb 03 15:25:58 <adrianschmutzler> because wpad-basic is defined as DEFAULT_DEVICE_PACKAGES (IIRC), and then you have to provide the "-wpad-basic wpad-mini" per device also in menuconfig to actually deselect it.
Feb 03 15:26:22 <adrianschmutzler> Anyway, I will be AFK now, good luck
Feb 03 15:28:17 <urjaman> yeah thanks
Feb 03 16:33:08 <urjaman> https://bugs.openwrt.org/index.php?do=details&task_id=50 apparently this non-reporting of failed image build has already been reported
Feb 03 16:33:20 <urjaman> in 2016
Feb 03 21:57:54 <valku> Is there a way to determine endianness of the target platform during cross-compilation?
Feb 03 22:00:02 <DonkeyHotei> are you porting to a new target?
Feb 03 22:01:11 <valku> No, I am trying to find a fix to an existing issue with nginx where the endianness test fails during cross-compilation. The fallback option is "big endian", and therefore nginx does not work properly on any little endian platform (such as x86_64).
**** ENDING LOGGING AT Tue Feb 04 03:00:51 2020