hanetzer has quit [Remote host closed the connection]
zer0def has quit [Remote host closed the connection]
<russell-->
there is a timeout so it doesn't run forever
romany0 has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
zer0def has joined #openwrt-devel
Tusker has joined #openwrt-devel
<Tusker>
heya guys, it looks like mr33 doesn't like the kernel 5.15 bump, it hangs after decompressing the kernel. The obvious thing I can see is that the kernel is now over 4MB, which could be the culprit, anyone experience something similar ?
<Tusker>
22.0.3 boots fine, on 5.10.161 at 3.8MB
srslypascal has quit [Ping timeout: 480 seconds]
GNUmoon has quit [Remote host closed the connection]
<Znevna>
how come the kernel is that huge?
<Tusker>
maybe something broken on my build machine
<Tusker>
i did a distclean, but maybe something hanging around
robimarko has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
<Tusker>
but, given that there isn't much difference between 3.8MB and 4.1MB it is probably normal on this target
<Znevna>
the kernel partition is defined with a size of 4MB on many devices, that's why I ask
srslypascal has joined #openwrt-devel
<Tusker>
i think the mr33 stores the kernel on an ubi partition and boot from there. it uncompresses and crc32+ and sha1+ hash integrity seems OK
<Tusker>
let's see if the snapshot build boots on 5.15, to see if it's just my environment causing issues
<Tusker>
OK... odd snapshot boots fine
<Tusker>
and kernel is even bigger at 4.3MB
xback has joined #openwrt-devel
ptudor has quit [Ping timeout: 480 seconds]
ptudor has joined #openwrt-devel
<Tusker>
job for tomorrow, will see how the snapshot behaves after the bump to 5.15.89
<Tusker>
thanks for the sounding board :)
gladiac has joined #openwrt-devel
hexagonwin has joined #openwrt-devel
srslypascal is now known as Guest2178
srslypascal has joined #openwrt-devel
Guest2178 has quit [Remote host closed the connection]
srslypascal has quit [Ping timeout: 480 seconds]
xback has quit [Ping timeout: 480 seconds]
<russell-->
hmm, so i kill the iptables rule blocking ssh, i empty the /var/passwd hash for user admin, and try to login (with three deprecated settings) and see this on the console: "user 'admin' has blank password, rejected", which implies it is looking in the file i changed, then i try a hash for a known password (copy/pasted from an openwrt box) and get a permission denied, implying it is using a
<russell-->
different hashing algorithm than modern openwrt. telnet also fails with empty hash or openwrt-derived hash.
<russell-->
the dropbear ssh on it is v0.46 (circa July 2005)
<dwfreed>
try md5crypt
<dwfreed>
hmm, or is openwrt still doing md5crypt ($1$)
<dwfreed>
my 19.07 device is md5crypt, but, well, that's 19.07, which is a bit crusty
<neggles>
russell--: reverse shell time!
<neggles>
does it have bash or no?
guerby has quit [Read error: Connection reset by peer]
<russell-->
i also tried "openssl passwd -1" on the device to create the hash
guerby has joined #openwrt-devel
<dwfreed>
russell--: probably need legacy crypt
<russell-->
i managed to remount rootfs (jffs2) rw and modify the inittab to give me a real shell, required a space after the comma in mount -o remount,rw /
<dwfreed>
whack
<russell-->
that'll be more comfortable than the limited shell provided by /bin/consoled
<dhewg>
jow: commented there, but still confused by it
<dhewg>
any rough idea how ipq40xx compared to ipx50xx?
<dhewg>
*compares
<robimarko>
In what sense?
<Ansuel>
i think ipq60xx is comparable to ipq40xx
<robimarko>
ipq50xx is just a cut down ipq60xx
<robimarko>
Where they removed 2 cores
<Ansuel>
so it's 2 core + 1 nss
<Ansuel>
and lower clk ?
<robimarko>
Depends on the exact model
<robimarko>
Its biggest upshot is that has the 2.4G AX radio fully embedded inside
<schmars[m]>
there are ipq40xx boards with 4 cores (e.g. fritzbox 4040 and many mikrotiks)
<robimarko>
All ipq40xx models are quad core
<schmars[m]>
got it, i read that ipq50xx 2 core wrong
<robimarko>
Ansuel: I love that they say Dual-core ARM Cortex-A53 at 1.0 GHz
<robimarko>
But actually run it higher
<schmars[m]>
maybe the clocking is part of the licensing
<schmars[m]>
* of the arm licensing
<Ansuel>
depends on the fuses
<Ansuel>
i guess
<robimarko>
Hehe, they are actually running it at 1.3GHz
<robimarko>
And they dumbed it down so that you dont even need a PMIC
<Ansuel>
what i love is that they are starting to call nss core NPU LOL
<robimarko>
Its been that forever
<robimarko>
It was always advertised as Network Processing Unit
<Ansuel>
and that is now problematic since now NPU is Neural Processing Unit
<Ansuel>
but for ipq is Network Processing Unit
<robimarko>
Who cares, these get reused all of the time
<Ansuel>
marketing magic people will think they are AI cores
<robimarko>
Nah
<robimarko>
These things dont even have marketing
<robimarko>
Their marketing is being cheap as chips
<robimarko>
Heck, they even have a model with RAM embedded on the die
<dhewg>
I meant as in performance, cut down ipq6 doesn't tell much how it stands against ipq4
<dhewg>
if avm indeed ships it, I guess it's not an insignificant step up since a new soc costs more than a few engineering hours
<Ansuel>
new wifi better core type
<Ansuel>
64bit
<Ansuel>
better soc in general
<Ansuel>
nss core
<dhewg>
is nss supported at all? mainline and/or here?
<Ansuel>
avm use qsdk
<Ansuel>
on openwrt in theory we can since they started providing nss firmware but it's a nightmare driver wise
<robimarko>
Its Cortex-A53 so way better than A7 found in ipq40xx, and it has AX radio
<dhewg>
is that 6/6e too?
<robimarko>
Thanks to Ansuel, NSS-DRV now works without using removed asm instructions for DMA with the generic DMA API
<robimarko>
dhewg: The embedded radio is 2.4G AX only
<robimarko>
So they put multiple PCIe controllers
<robimarko>
And have companion 6/6e cards
<Ansuel>
do you know how much line?
<Ansuel>
considering dsl is one line
<robimarko>
You mean PCIe lines?
<Ansuel>
yes
<robimarko>
1 x PCIe 2.0 X2 + 1 x PCIe 2.0 + 1 x USB 2.0 or
<robimarko>
1 x PCIe 2.0 X2 + 1 x USB 3.0
<robimarko>
Do note that there is no built-in switch anymore
<Ansuel>
edmav2 ?
<robimarko>
Only one SGMII/SGMII+
<robimarko>
Nope
<robimarko>
EDMAv2 is IPQ9574
<robimarko>
This is just another variation of EDMAv1
<Ansuel>
but external
<robimarko>
?
<robimarko>
The PHY is external yes
<robimarko>
But its always been like that
<Ansuel>
wonder what magic they use to comunicate with nss since it's not built-in
<robimarko>
What do you mean its not built-in?
<robimarko>
It is built-in the SoC
<Ansuel>
you said no built-in switch
<robimarko>
Yes
<robimarko>
NSS runs on the UBI32 NPU core
<robimarko>
Which is in the SoC
<robimarko>
Always has been
<robimarko>
Switch is just a switch
<robimarko>
My favorite model is IPQ0509 which has 256MB of RAM built-in
<Ansuel>
the die must be big
<Ansuel>
also how that means less production cost o.O
<robimarko>
Cause its probably the same size as IPQ807x
<robimarko>
I am sure they are making a profit
<Ansuel>
we are at the point where ram in die is cheaper than some trace on the pcb wow...
valku has joined #openwrt-devel
<robimarko>
I suspect there will be a flood of these ipq50xx models
<robimarko>
There is already quite a lot of them in ODM designs
<robimarko>
I did have an issue with reboot not working for some reason on my Motorola Q14
<robimarko>
Need to test on EAP104 to see if its happening there as well
<Ansuel>
probably really easy to develop considering you don't need to care about ram and regulators are easy
<robimarko>
SW wise you dont care about RAM anyway
<robimarko>
They train that in SBL
<robimarko>
And yeah, it only needs couple of rails and they recommend just using LDO-s
<Ansuel>
i mean hw side
<robimarko>
There are only 2 models with RAM built-in
<robimarko>
All of the production has been with external RAM
<robimarko>
As they are doing triple radios so 256MB aint gonna cut it
<robimarko>
BTW, did you have time to poke at the crypto?
<robimarko>
I think its panicking on spin unlock for some reason?
<Ansuel>
it seems strange that it does panic at spinlock
<robimarko>
I agree
<robimarko>
I though it was a NULL pointer on kfree
<robimarko>
Still no idea how to use decode_stacktrace with kmods on OpenWrt
srslypascal has joined #openwrt-devel
<Ansuel>
well the print don't lie
<Ansuel>
user must be NULL
<robimarko>
I agree with you
<robimarko>
However, it doesnt panic on spin_lock_bh(&user->lock);
<robimarko>
And if user was NULL it would have to crap out instantly
<Ansuel>
well where user is used?
<Ansuel>
in nss_cryptoapi_copy_iv i guess?
<robimarko>
In everything generic
<robimarko>
Its the nss-crypto abstraction
<robimarko>
Lets continue this on the forum, to not spam here
<Ansuel>
ok
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
<dhewg>
Ansuel: do you plan to look at the luci part of the iwinfo changes?
<Ansuel>
pretty busy at the moment but the big change for the wifi chanel to extend the limits to an array is there and done
<Ansuel>
currently it's all driven by a variable true or false
<dhewg>
you mean that available var from your PR?
xback has joined #openwrt-devel
<dhewg>
I meant PR6104 :)
<xback>
Looks like sysupgrade is broken on imx target
<xback>
it still scans the nand for badblocks, but doesnt not erase/reprogram it
<xback>
does not*
<Ansuel>
imx use emmc ?
<xback>
nand
srslypascal has quit [Ping timeout: 480 seconds]
aiyion has joined #openwrt-devel
aiyion_ has quit [Ping timeout: 480 seconds]
<xback>
aah .. found the offending commits ..
goliath has quit [Quit: SIGSEGV]
minimal has joined #openwrt-devel
aiyion has quit [Remote host closed the connection]
goliath has joined #openwrt-devel
gch9812133 has joined #openwrt-devel
gch981213 has quit [Ping timeout: 480 seconds]
gch9812133 is now known as gch981213
Borromini has joined #openwrt-devel
gladiac has joined #openwrt-devel
hexagonwin has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
xback has quit [Remote host closed the connection]
xback has joined #openwrt-devel
<mrkiko>
I would like to be sure - does openwrt use the "firmware" partition name in some scripts to do things? I'm in the process of upstreaming a mvebu DTS, and I am asked to identify "u-boot" as firmware, due to the (very valid) reason that in that platform, the u-boot partition contains "TIM firmware + wtmi + u-boot". The device I'm looking at is gl-mv1000 (emmc) so this shouldn't constitute a problem,
<robimarko>
mrkiko: Yes, by default it is using the "firmware" name
<robimarko>
But these days the proper name is usually set in upgrade scripts and there is compatibles for mtd parsers as well
<robimarko>
You are gonna have to name it "firmware" as it makes sense, not only u-boot is there
hexagonwin has joined #openwrt-devel
lucenera8 has joined #openwrt-devel
hexagonwin has quit [Remote host closed the connection]
Borromini has quit [Ping timeout: 480 seconds]
lucenera has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
lucenera8 has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
lucenera8 has joined #openwrt-devel
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
AtomiclyCursed has joined #openwrt-devel
lucenera85 has joined #openwrt-devel
lucenera8 has quit [Ping timeout: 480 seconds]
lucenera858 has joined #openwrt-devel
lucenera858 has quit []
lucenera has joined #openwrt-devel
<mrkiko>
robimarko: yeah, indeed
lucenera85 has quit [Ping timeout: 480 seconds]
<mrkiko>
robimarko: still wanted to avoid situations where an user sysupgrades and finds no u-boot then :D
<mrkiko>
robimarko: then, another thing is - I am being asked (righly) to defined kernel part, rootfs part and rootfs_data part in DTS. But I am scared this is not feasible due to the fact those offsets will change any time the stock firmware gets upgraded for some reasons
<mrkiko>
will have to look at that to understand if that's the case, but I think it is
lucenera6 has joined #openwrt-devel
<robimarko>
Well, defining those upstream has just caused them to get patched downstream
<mrkiko>
robimarko: ok, so it makes no sense ... wish I knew better
<mrkiko>
robimarko: gl.iNet didn't define any of them when submitting thedts upstream
<mrkiko>
upstream = openwrt
<robimarko>
Which device are you upstreaming?
<mrkiko>
gl-mv1000 /mvebu)
lucenera6 has quit []
lucenera2 has joined #openwrt-devel
lucenera2 has quit []
<robimarko>
Well, it really makes no sense to define kernel, rootfs and rootfs_data separately
<robimarko>
That is what we have parsers for to dynamically create rootfs_data
<robimarko>
But, on that device, NOR is not used for OpenWrt at all?
lucenera has quit [Ping timeout: 480 seconds]
lucenera9 has joined #openwrt-devel
lucenera9 has quit []
lucenera has joined #openwrt-devel
<mrkiko>
robimarko: no, it's not used at all - unless you mess with the env
srslypascal has quit [Ping timeout: 480 seconds]
<mrkiko>
robimarko: so - in openwrt I did a mistake, probably I should keep just u-boot, u-boot-env and dtb, right? And maybe rename u-boot to firmware ? But then how can I define the rest?
<mrkiko>
and in a way that is acceptable upstream
<mrkiko>
nice to know CONFIG_TARGET_PREINIT_TIMEOUT
<lucenera>
Are the mount options for rootfs hardcoded somewhere?
<mrkiko>
robimarko: I mean, ideally to have parser split partitions automatically in openwrt even tough they're not used, and if possible in upstream Linux as well ? never looked at this part of things