gch9812130 has quit [Read error: Connection reset by peer]
gch98121309 is now known as gch9812130
Ycarus has joined #openwrt-devel
allotrope94 has quit [Remote host closed the connection]
allotrope94 has joined #openwrt-devel
koniu has joined #openwrt-devel
danitool has joined #openwrt-devel
danitool has quit [Remote host closed the connection]
opal has quit [Ping timeout: 240 seconds]
opal has joined #openwrt-devel
feriman has joined #openwrt-devel
eduardas has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
gch98121301 has joined #openwrt-devel
gch9812130 has quit [Read error: Connection reset by peer]
gch98121301 is now known as gch9812130
linzst has joined #openwrt-devel
gch9812130 has quit [Read error: Connection reset by peer]
gch9812130 has joined #openwrt-devel
Redfoxmoon has quit [Read error: Connection reset by peer]
Redfoxmoon has joined #openwrt-devel
Redfoxmoon has quit [Changing host]
Redfoxmoon has joined #openwrt-devel
gch9812130 has quit [Quit: Ping timeout (120 seconds)]
gch9812130 has joined #openwrt-devel
Darkmatter66 has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #openwrt-devel
Ivan_83 has quit [Quit: Miranda NG]
Ivan83 has joined #openwrt-devel
gch98121305 has joined #openwrt-devel
gch9812130 has quit [Read error: Connection reset by peer]
gch98121305 is now known as gch9812130
dxld has quit [Quit: Bye]
dxld has joined #openwrt-devel
<karlp>
yay. just sysupgraded a zbt-we1326, from an old master, liek 2018, kept settings, and... it's bootlooping :)
<karlp>
lzma error on uncompression,
koniu has quit [Remote host closed the connection]
<rsalvaterra>
karlp: Maybe it's the users issue?
<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?
koniu has joined #openwrt-devel
<rsalvaterra>
Have you tried booting in fail-safe mode?
<karlp>
rsalvaterra: it doesn't get that far, it's uncompressing kernel and then aborts and returns to the rom bootloader
<karlp>
just soldering pins on it so I can actually try typing in uboot instead of holding a serial dongle down
<rsalvaterra>
Ah, right, missed the lzma error.
<karlp>
is that likely to be a "kernel got too big, no options until bootloader updated?"
daregap has quit [Quit: daregap]
<zorun>
I've seen some devices being switched to lzma-loader (no idea if it requires something from the bootloader)
<f00b4r0>
zorun: and some devices being switched out of lzma-loader as well, due to -ETOOMANYBUGS :)
<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 ;)
MarioH has joined #openwrt-devel
<karlp>
hehe, someone has already added it to the other zbt 3526,
<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?
<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 :)
<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) :)
victhor has joined #openwrt-devel
<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.
<f00b4r0>
gch981213: ok, I guess I'm confused then. The kernel already has self-relocation, including in raw (non-elf) mode
<karlp>
ok, 19.7.4 release worked, via the factory "recovery" bootloader,
* karlp
waits on teh master build with lzma loader
<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?)
<f00b4r0>
err, no?
<gch981213>
f00b4r0: kernel still has to be put exactly where it's linked to before that relocation is executed.
<f00b4r0>
last time I checked MIPS head.S
<f00b4r0>
it has a stub to handle the case where the kernel is executed from its start address (vs load) and relocates itself accordingly
<f00b4r0>
in fact, lzma-loader's relocation code is copy pasted from that code, afaict
<f00b4r0>
in the kernel head.S the comment says something like "get a fighting chance at booting" or somesuch
<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.
<f00b4r0>
* We might not get launched at the address the kernel is linked to,
<f00b4r0>
so we jump there. */
<gch981213>
f00b4r0: There's no copying before that.
<gch981213>
I've tried it before I checked head.S and it caused some exception caught by u-boot handler.
<f00b4r0>
if I'm reading this right, if CONFIG_RELOCATABLE is enabled it should address this?
<gch981213>
f00b4r0: I've tried. It doesn't.
<f00b4r0>
interesting
<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?
<gch981213>
f00b4r0: No. It decompresses kernel to its load address and no copying happens after decompressing.
koniu has quit [Remote host closed the connection]
<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.
<f00b4r0>
ah right. rereading, lzma-loader copies itself out of the way first
koniu has joined #openwrt-devel
<f00b4r0>
still a bit of overhead, not as bad as I thought
Acinonyx_ has joined #openwrt-devel
valku has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 256 seconds]
feriman has quit [Ping timeout: 272 seconds]
al has joined #openwrt-devel
Snowbl1nd has quit [Ping timeout: 244 seconds]
Snowblind has joined #openwrt-devel
decke has quit [Quit: Leaving.]
allotrope94 has quit [Read error: Connection reset by peer]
allotrope94 has joined #openwrt-devel
ylk has joined #openwrt-devel
ylk has quit [Remote host closed the connection]
PtitGNU has quit [Remote host closed the connection]
PtitGNU has joined #openwrt-devel
gch981213 has quit [Quit: Ping timeout (120 seconds)]
gch981213 has joined #openwrt-devel
allotrope94 has quit [Ping timeout: 260 seconds]
allotrope94 has joined #openwrt-devel
swex has quit [Ping timeout: 260 seconds]
allotrope94 has quit [Ping timeout: 264 seconds]
allotrope94 has joined #openwrt-devel
JuniorJPDJ has quit [Quit: Idle for 30+ days]
luaraneda has quit [Quit: Idle for 30+ days]
codekaust has quit [Quit: Idle for 30+ days]
magnusk has quit [Quit: Idle for 30+ days]
shalzz has quit [Quit: Idle for 30+ days]
sielicki has quit [Quit: Idle for 30+ days]
linzst has joined #openwrt-devel
zzzz has joined #openwrt-devel
<zzzz>
Hello, I am new here, do we have a 5g wifi stable build for linksys wrt1200ac? mwlwifi seems not fully working
allotrope94 has quit [Ping timeout: 264 seconds]
allotrope94 has joined #openwrt-devel
eduardas has quit [Quit: Konversation terminated!]
<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
<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.