**** BEGIN LOGGING AT Fri Nov 06 02:59:57 2020
Nov 06 03:04:03 <aparcar[m]> mangix: what brought you back on the APK train?
Nov 06 05:11:16 <damex> stintel: thanks :D finally it is merged...
Nov 06 05:11:32 <damex> hopefully er6 and er12 could be next ;p
Nov 06 11:41:01 <karlp> yay. just sysupgraded a zbt-we1326, from an old master, liek 2018, kept settings, and... it's bootlooping :)
Nov 06 11:41:20 <karlp> lzma error on uncompression,
Nov 06 11:55:31 <rsalvaterra> karlp: Maybe it's the users issue?
Nov 06 11:55:56 <eduardas> hello, can anyone provide me with a definitive answer whether it is possible to boot an aarch64 Linux kernel using a 32-bit (ARMv7) compiled mainline u-boot?
Nov 06 11:56:00 <rsalvaterra> Have you tried booting in fail-safe mode?
Nov 06 12:02:29 <karlp> rsalvaterra:  it doesn't get that far, it's uncompressing kernel and then aborts and returns to the rom bootloader
Nov 06 12:02:52 <karlp> just soldering pins on it so I can actually try typing in uboot instead of holding a serial dongle down
Nov 06 12:03:00 <rsalvaterra> Ah, right, missed the lzma error.
Nov 06 12:15:11 <karlp> is that likely to be a "kernel got too big, no options until bootloader updated?"
Nov 06 12:24:04 <zorun> I've seen some devices being switched to lzma-loader (no idea if it requires something from the bootloader)
Nov 06 12:27:56 <f00b4r0> zorun: and some devices being switched out of lzma-loader as well, due to -ETOOMANYBUGS :)
Nov 06 12:49:03 <f00b4r0> completely OT: does anyone here have experience with ulfius? https://github.com/babelouest/ulfius
Nov 06 13:02:39 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 100.0% packages reproducible in our current test framework.)
Nov 06 13:26:32 <gch9812130> karlp: That's the exact issue we solved using lzma-loader
Nov 06 13:28:48 <gch981213> f00b4r0: It's just "we aren't smart enough to figure out what's wrong with it." :)
Nov 06 13:29:19 <karlp> so... it needs soem | lzma-magic | added to the image makefiles?
Nov 06 13:30:20 <gch981213> karlp: add a $(Device/uimage-lzma-loader) to your device recipe and see if it works.
Nov 06 13:30:32 <karlp> aight, thanks.
Nov 06 13:39:34 <f00b4r0> gch981213: heh. IMO it's always much cleaner to boot vanilla-compressed kernel anyway, that's why I'm very happy to see this happening now ;)
Nov 06 13:41:18 <karlp> hehe, someone has already added it to the other zbt 3526,
Nov 06 13:42:50 <f00b4r0> gch981213: btw, I was under the impression that your patch meant zboot could now be used in place of lzma-loader for uboot devices?
Nov 06 13:43:19 <gch981213> f00b4r0: It's just another loader anyway. An actual improvement would be that we can consult smarter people upstream if anything is wrong with it :)
Nov 06 13:44:00 <f00b4r0> gch981213: well, it's upstream's loader: it certainly sees a lot more coverage and testing than whatever we come up with. And it's maintained (hopefully) :)
Nov 06 13:44:35 <gch981213> f00b4r0: It's possible. Either fetch the load address from ELF as john-tho proposed in the PR or implement self-relocation as what lzma-loader did.
Nov 06 13:45:27 <f00b4r0> gch981213: ok, I guess I'm confused then. The kernel already has self-relocation, including in raw (non-elf) mode
Nov 06 13:47:05 <karlp> ok, 19.7.4 release worked, via the factory "recovery" bootloader,
Nov 06 13:47:25 * karlp waits on teh master build with lzma loader
Nov 06 13:48:32 <gch981213> f00b4r0: The self-relocation done by lzma-loader is: "we can execute it anywhere and it will copy itself back". The kernel one is: "It copies itself to a (maybe random) address" (so that malicious people can't find where the kernel code is in memory from load address in binary I guess?)
Nov 06 13:49:06 <f00b4r0> err, no?
Nov 06 13:49:10 <gch981213> f00b4r0: kernel still has to be put exactly where it's linked to before that relocation is executed.
Nov 06 13:49:14 <f00b4r0> last time I checked MIPS head.S
Nov 06 13:49:37 <f00b4r0> it has a stub to handle the case where the kernel is executed from its start address (vs load) and relocates itself accordingly
Nov 06 13:49:50 <f00b4r0> in fact, lzma-loader's relocation code is copy pasted from that code, afaict
Nov 06 13:50:33 <f00b4r0> in the kernel head.S the comment says something like "get a fighting chance at booting" or somesuch
Nov 06 13:51:49 <gch981213> f00b4r0: I remember some code around that tells me it can't be put at random place. It's a jump with absolute address. I'll go check it now.
Nov 06 13:52:03 <f00b4r0> https://elixir.bootlin.com/linux/latest/source/arch/mips/kernel/head.S#L73
Nov 06 13:52:04 <f00b4r0> this
Nov 06 13:52:26 <f00b4r0> and further down: -
Nov 06 13:52:28 <f00b4r0> * We might not get launched at the address the kernel is linked to,
Nov 06 13:52:28 <f00b4r0> 	   so we jump there.  */
Nov 06 13:53:03 <gch981213> f00b4r0: There's no copying before that.
Nov 06 13:53:57 <gch981213> I've tried it before I checked head.S and it caused some exception caught by u-boot handler.
Nov 06 13:55:08 <f00b4r0> if I'm reading this right, if CONFIG_RELOCATABLE is enabled it should address this?
Nov 06 13:55:24 <gch981213> f00b4r0: I've tried. It doesn't.
Nov 06 13:55:31 <f00b4r0> interesting
Nov 06 14:01:24 <f00b4r0> aside the potential bugs issue, my understanding is there is some overhead to using lzma-loader, due to the way it packs the payload: it decompresses, then copies, so it needs memory space for the compressed payload, and twice the decompressed so it can copy without clobbering; where AIUI, zboot decompresses "in place" where the kernel expects to be, right?
Nov 06 14:06:05 <Hauke> a free prpl event starts in about 2 hours: https://www.eventbrite.com/e/prpl-summit-preview-event-tickets-126785225021
Nov 06 14:06:14 <gch981213> f00b4r0: No. It decompresses kernel to its load address and no copying happens after decompressing.
Nov 06 14:07:56 <gch981213> zboot knows how big the decompressed kernel is and linked itself after decompressed kernel. lzma-loader don,t know about that and we currently linked it at 32M memory, meaning kernel bigger than that will override lzma-loader code.
Nov 06 14:08:45 <f00b4r0> ah right. rereading, lzma-loader copies itself out of the way first
Nov 06 14:08:55 <f00b4r0> still a bit of overhead, not as bad as I thought
Nov 06 16:46:50 <zzzz> Hello, I am new here, do we have a 5g wifi stable build for linksys wrt1200ac? mwlwifi seems not fully working
Nov 06 17:11:09 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 99.7% packages reproducible in our current test framework.)
Nov 06 18:53:01 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Nov 06 20:09:16 <aparcar[m]> mangix: ping
Nov 06 20:15:57 <jg_> jow:I'm struggling to get 19.07.04 installed on a Ubiquiti unifi mesh. The first problem I had was the new feature that it would revert its configuration after a minute or so, and as I had changed the address to a separate subnet, it would revert my configuration. It nicely tells you about this after this interval, but I was going ahead and trying to access it at the new address on the new subnet, which would fail. And something about the reversion w
Nov 06 20:15:57 <jg_> as problematic, as I kept having to reset the device to factory defaults until I eventually saw the dialog which allowed me to force the configuration, which worked successfully.
Nov 06 20:16:39 <jg_> my second problem I haven't solved yet....
Nov 06 20:31:43 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Nov 06 22:04:34 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Nov 07 02:47:31 <csrf> does openwrt use a specific js framework for its mvc rendering?
Nov 07 02:47:56 <csrf> I see that it uses bootstrap for presentation/styling
Nov 07 02:48:45 <csrf> is there any documentation/wiki on how the luci mvc stuff works?
Nov 07 02:48:57 <csrf> coding guidelines or something similar?
**** ENDING LOGGING AT Sat Nov 07 03:00:32 2020