<Namidairo>
rsalvaterra: I don't remember adding any mediatek-bmt tags in the dts...
<dangole>
mangix: if your device worked well previously there won't be any difference. however, devices which actually do have some bad blocks in the area where the kernel is stored will now have working sysupgrade (which previously couldn't work because on mt7621 target there was no support for BMT/BBT in kernel)
<aparcar>
mangix: I think I fixed your bug
<mangix>
aparcar: it's Pepe's, not mine
<aparcar>
I mean the CI stuff
pmelange has left #openwrt-devel [#openwrt-devel]
<mangix>
right
<rsalvaterra>
dangole: Mine has a bad block, but falls inside the ubi partition.
<dangole>
mangix: not recently, but i had a look some months ago
<mangix>
OK
<dangole>
mangix: and looking at it again: yes, this should have BBT/BMT with ubi-region excluded as well.
<rsalvaterra>
Namidairo: But it could be much worse… at least it's SLC NAND.
<mangix>
dangole: I noticed the ea7xxx dts has alt_kernel and alt_rootfs. Any reason to also adapt it to the E7350? It currently just has alt_firmware.
<Namidairo>
they usually spec the first bit of the flash as clean though
<Namidairo>
so the crucial bits like bootloader will usually be fine.
<dangole>
mangix: using automated mtd-splitters on a single firmware partition is nicer than hard-coding the sizes, as kernel-size may need to be increased in future. just not always possible, due to vendor loader limitations.
<Namidairo>
half the loaders having broken lzma on that platform does not help
<dangole>
Namidairo: I also saw excessive forward error correction for SPL on NAND, followed by having everything in UBI (e.g. oxnas burned-in romloader uses x8 FEC). in that way, no guarantees are needed.
<mangix>
dangole: right. I noticed nbd's commit applies bbt to both the kernel and alt_kernel. So for this router, either apply it to the kernel only, or for both kernel and alt_kernel. no idea if the latter needs to be separated out in dts from alt_firmware or just referenced with offsets.
<dangole>
mangix: you should store rootfs in UBI as well, so it's better to just have alt_kernel in first place, and have both kernel and alt_kernel (and uboot-env, ...) covered by BBT.
<dangole>
mangix: sorry, that was confused. looking at the dts, this is really just naming
<dangole>
mangix: so on this board, 0x0-0x580000 and 0x3180000-$end_of_flash should be covered by BBT/BMT, skipping only the UBI area and assuming OpenWrt will always be installed into primary boot slot, leaving vendor firmware in alt_firmware slot
<mangix>
hmmm OK
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
dangole has quit [Remote host closed the connection]
arifre has quit [Remote host closed the connection]
<rsalvaterra>
xback: I'm carrying it in my tree, yes. :)
<rsalvaterra>
I haven't done any performance measurements, though. But mangix wrote the initial patch, maybe he has more details.
<rsalvaterra>
We wanted to send this patch upstream, but getting performance number would be pretty much impossible, since the upstream driver is different from ours (and doesn't actually work, from what I've been told).
<mangix>
the upstream driver works but only with ar9331 and other similar old SoCs
<mangix>
none of which I have
<rsalvaterra>
Anyway, I can't imagine how a patch to remove false sharing of cache lines would *hurt* performance. :P
<mangix>
i could
<rsalvaterra>
mangix: Right, I only have AR9344 and QCA9563.
<rsalvaterra>
mangix: Yes, if the number of cache lines used would increase.
<rsalvaterra>
Data cache pressure.
<mangix>
making the struct smaller just saves RAM size
<mangix>
i don't think the full ag71xx_int_stats struct is used
Grommish has joined #openwrt-devel
pmelange has joined #openwrt-devel
Grommish_ has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest549
srslypascal has joined #openwrt-devel
pmelange1 has joined #openwrt-devel
pmelange1 has quit []
pmelange1 has joined #openwrt-devel
pmelange has quit [Quit: Leaving.]
pmelange has joined #openwrt-devel
Guest549 has quit [Ping timeout: 480 seconds]
pmelange1 has quit [Ping timeout: 480 seconds]
floof58 has quit [Read error: No route to host]
floof58 has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
dangole has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
GNUmoon has quit [Ping timeout: 480 seconds]
GNUmoon has joined #openwrt-devel
<nitroshift>
mangix, i closed the issue with transmission-daemon, it's wolfssl's fault
<nitroshift>
it works ok with openssl / polarssl
gladiac is now known as Guest551
gladiac has joined #openwrt-devel
Guest551 has quit [Ping timeout: 480 seconds]
floof58_ has joined #openwrt-devel
floof58 has quit []
Grommish_ has joined #openwrt-devel
Grommish has quit [Ping timeout: 480 seconds]
Grommish_ has quit [Ping timeout: 480 seconds]
Grommish has joined #openwrt-devel
guidosarducci has joined #openwrt-devel
guidosarducci_ has quit [Ping timeout: 480 seconds]
Grommish_ has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
Grommish has quit [Ping timeout: 480 seconds]
Acinonyx_ has quit [Ping timeout: 480 seconds]
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
rua has quit [Remote host closed the connection]
dedeckeh has joined #openwrt-devel
rua has joined #openwrt-devel
Grommish has joined #openwrt-devel
Grommish_ has quit [Ping timeout: 480 seconds]
nitroshift has quit [Quit: Gone that way --->]
victhor has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
tohojo has joined #openwrt-devel
danitool has joined #openwrt-devel
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<aparcar>
[florian]: ideas on how we could debug the usage of an external toolchain together? I'd be delighted to speed up CI builds
<stintel>
ugh. next issue. when booting from flash: Uncompressing Kernel Image ... lzma compressed: uncompress error 1
<stintel>
if I change the KERNEL_LOADADDR from mt7621 default (0x80001000) to what OEM uses (0x81001000), that lzma error disappears, but the kernel doesn't boot.
<stintel>
also with KERNEL_LOADADDR 0x81001000 the initrd also no longer boots
danitool_ has joined #openwrt-devel
danitool has quit [Read error: Connection reset by peer]
<stintel>
do we have any documentation about lzma-loader, what it does and why that is needed in some cases?
danitool_ has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<dangole>
stintel: i don't think there is any documentation for that. it's basically just an intermediate loader you can use in case of stock loader being to broken to load kernel. it requires memory-mapped access to the flash and decompresses kernel and starts it.
SamantazFox has quit [Remote host closed the connection]
SamantazFox has joined #openwrt-devel
<stintel>
it would help if someone who really understands all of that stuff does a detailed writeup about it ... I found that now by trial and error but I have very little clue about why it's needed
<stintel>
and if there are possibly cleaner ways to solve it
<stintel>
I had to change LZMA_TEXT_START which isn't even set from a variable, so it's impossible to override on device level
<stintel>
so I'm having a hard time believing this is the only way to fix the problem, otherwise that LZMA_TEXT_START would be set from a variable already
<dangole>
LZMA_TEXT_START is the location in RAM (ie. somewhere in memory-mapped SPI-NOR area in phys ram) where the loader will start decompressing from. that depends on the flash layout, ie. where you are writing the loader and subsequent compressed data.
<dangole>
stintel: vendors are never shy to introduce unbelievable amounts of useless complexity in the boot firmware (such as hard-coded size limits or stupid load address in ram with not a lot of space above) to break it for any but their own use-case.
cmonroe_ has joined #openwrt-devel
rua1 has joined #openwrt-devel
rua has quit [Remote host closed the connection]
cmonroe has joined #openwrt-devel
cmonroe_ has quit [Ping timeout: 480 seconds]
<f00b4r0>
stintel: IIRC (I last looked at that code last year) lzma_loader reads an lzma-compressed kernel from LZMA_TEXT_START and expands it from LOADADDR, sets up cmdline and jumps
<f00b4r0>
stintel: then there are several incarnations of it living in various subtargets, so your mileage may vary
<f00b4r0>
I had written something about it, let's see if I can find it again
<f00b4r0>
in-between I may have forgotten a step where it first moves the compressed data in place before uncompressing
victhor has quit [Remote host closed the connection]
<f00b4r0>
stintel: I can't find my notes. If you have a specific question feel free to ask it may jog my memory.
<f00b4r0>
also I don't remember LZMA_TEXT_START belonging to mapped SPI, IIRC everything is in RAM
<Slimey>
where are the wpa_supplicant logs stored?
<dwfreed>
they aren't; you can read them with logread
<dwfreed>
openwrt does not write logs to disk because it would quickly wear out the flash on most consumer devices
<PaulFertser>
Slimey: moreover, wpa_supplicant is compiled with most messages stripped out by default.
<PaulFertser>
Slimey: so even with elevated debug level you won't be getting more info.
srslypascal is now known as Guest573
srslypascal has joined #openwrt-devel
<rmilecki>
stintel: i can only answer why we need that
<rmilecki>
stintel: we need LZMA compression as that is more optimal
<rmilecki>
i should probably say: it results in smaller kernel size
<rmilecki>
not every bootloader supports LZMA
<rmilecki>
do we have LZMA loader
<stintel>
ok that's the most obvious case, but in my case I had to use it work around an LZMA decompression error
<rmilecki>
LZMA loader is small enough that it doesn't need to be LZMA compressed
<rmilecki>
so we use LZMA loader to allow LZMA compressed kernel
<stintel>
appreciate all the replies by the way
<rmilecki>
stintel: some bootloaders have broken LZMA support - they e.g. can't handle big LZMA compressed kernels
<rmilecki>
stintel: hauke understands those offsets
Guest573 has quit [Ping timeout: 480 seconds]
<stintel>
thanks!
<rmilecki>
(sorry hauke :p )
<stintel>
:P
<stintel>
ok I'm out for the weekend, please do keep responding and/or link me to relevant documentation
<rmilecki>
stintel: check https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=4cd97e4760899172a1d6339ea5644992775e504e AND two commits I referenced in that commits body
<stintel>
once I understand all of that shit I'll try to compile some guide
<f00b4r0>
stintel: there are two decompression stages happening in that log
<f00b4r0>
if I read it correctly
<f00b4r0>
the first decompresses to 0x81001000, and loads that, which seems to be a second lzma-loader stage, which decompresses to 0x80001000 and loads that.
<f00b4r0>
and that looks wrong, obviously.
<stintel>
what log are you talking about?
<f00b4r0>
s/in that log/in the log posted in the first message of the forum/
<stintel>
ah
goliath has quit [Quit: SIGSEGV]
<f00b4r0>
the hint is "OpenWRT kernel loader" being shown after "Starting kernel..." from the bootloader
hexagonwin has quit [Remote host closed the connection]
<f00b4r0>
i see
<f00b4r0>
so as rmilecki suggested, it's probable the bootloader can't deal with big lzma-compressed kernels
<stintel>
but it can in the tftpboot case
<stintel>
which only adds to the confusion
<f00b4r0>
well, I'm not surprised. Though I've seen the opposite more often (not working tftboot, working flash boot). tftp boot process manages memory differently
<stintel>
oh, gotta run, friends' flight about to land early
<f00b4r0>
but I'm surprised to see lzma-loader itself lzma-compressed
<f00b4r0>
ok
<f00b4r0>
ttyl
<stintel>
suddenly appeared on my piaware :P
<stintel>
I think maybe fit lzma ... doesn't work if the lzma-loader isn't lzma compressed
<f00b4r0>
yes of course it wouldn't
<stintel>
not sure if can drop that lzma
<stintel>
from fit
<stintel>
I don't read Makefile fluently but to me it seemed that compression argument is non-optional
<f00b4r0>
I'm not fit-fluent tbh :)
<aparcar>
dangole: can we add tags to uclient etc? some alpine dev would like to add those packages to their repositories and would prefer tags rather than hashes
<f00b4r0>
anyway, I'm sure there are people more helpful than I for dealing with the shenanigans of fit images. I confess my ignorance here
<stintel>
will try that
<f00b4r0>
I just think that double lzma is not a great idea (it's bound to be slow and non-optimal)
<[florian]>
aparcar: was planning on looking into it this weekend
<aparcar>
[florian]: thank you
<dangole>
aparcar: i guess we could just tag the version which comes with each official OpenWrt release. it's a bit of work, we technically don't really need it and it's yet another aspect which needs to be maintained constantly. if we start to do that, we should use the tags also in our package builds as otherwise they will be subject to bitrot...
<Slimey>
PaulFertser nm got it
<aparcar>
dangole: I think it's a better approach than using the current "date" based appraoch
<aparcar>
but I can also ask that on the ML and see what people think
<dangole>
aparcar: we can use the date as tag name, that would at least eliminate the additional version number
<aparcar>
seems a bit awkward...
<aparcar>
dangole: do you mind briefly joining alpine-devel and discuss that with me and Aridiane?
<dwmw2_gone>
Has worked; not sure if you care about the messages.
<dwmw2_gone>
Thanks
<jow>
fine
<dwmw2_gone>
dangole: ↑ that was the mSATA support for U7623 fwiw
<dangole>
dwmw2_gone: did you test the latest iteration of the patch series consolidating dtsi+dts to a single dts and unifying the board-name/compatible-string?
svlobanov has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
<svlobanov>
hi. Is there any test.sh example for CI? I can't find any package with test.sh script as example
<jow>
svlobanov: the packages feed contains quite some test.sh examples