<dwfreed>
(my nbg with a 4 GB eMMC has only 2 MB in the bootX partitions, still probably plenty for u-boot)
<dwfreed>
granted, it uses a separate SPI flash for u-boot
<stintel>
hah noooo now my image doesn't have lua because luci ucode
<stintel>
and I'd need to port the openthread-br luci stuff
<slh>
the lower end Atom J1900/ c25xx/ e35xx based routers (gateprotect, sophos, trustwave, nuage networks, barracuda) would be a little too slow for cake @1 GBit/s (in a short iperf3 test, my j1900 based FW-7543 reached ~830 MBit/s). but any x86_64 device >= ivy-bridge would do 1 GBit/s sqm/ cake easily
<stintel>
can't be that *all* of luci was already rewritten in ucode, can it?
<dwfreed>
slh: yeah, but if I can get that firebox m300 for about $50 out the door, there's really not a better deal than that
<slh>
stintel: base luci should be ucode+js already, but there are still plenty of luci-app-* packages which aren't, yet
<stintel>
ah, luci-lua-runtime
<stintel>
is probably what I need :)
<slh>
dwfreed: ack (in my case fan noise, power consumption and the more exotic SOC made reconsider and favour x86_64 instead). I've seen M300 sell for around 20-25 EUR already (rarely, but possible), my gateprotect cost me 35 EUR (and only needs to do 400/200 MBit/s with sqm/cake in practice)
<stintel>
M300 is EOL end of this month so the market will potentially be flooded with them
<stintel>
(if WatchGuard actually have customers :P)
<stintel>
but yeah exotic
<dwfreed>
slh: x86 would be ideal, but cost is also a factor; don't think the fan noise will be a real issue on the m300 outside of startup
<dwfreed>
even though we only have 250 Mbit symmetric where this will be used, I would like to plan ahead for gigabit
<stintel>
if you're allergic to recurring warnings that might also be a reason against the m300
<stintel>
and binary firmware in the network processing unit, what was it called dpaa
<stintel>
aha, the thread section appeared in luci
<slh>
just for a comparison, I was using an ivy-bridge based c1037u mini-PC with two interface running at 15 watts the first of of this year (can do 1 GBit/s sqm/cake easily, plenty of CPU cycles left), now the gateprotect fw-7543 with baytrail-d Atom j1900 and 4 ethernet ports needs 11 watts and only gets to ~830 MBit/s while testing sqm/cake - both are silent (c1043u passively cooled, the fan in the
<slh>
gateprotect can spin down to be pretty much inaudible). both were tested in practice with 400/200 MBit/s ftth
<stintel>
there's an erratum for frequency scaling - it's completely disabled :(
<stintel>
I wonder if the powerpc notebook guys managed to figure a way around that
<Strykar>
there go the hopes of the fan spinning down?
<stintel>
meh the thread luci page throws errors
<stintel>
ah maybe because I'm missing kmod-usb-acm
nwf has joined #openwrt-devel
nwf__ has quit [Ping timeout: 480 seconds]
<stintel>
yep that was it
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
goliath has joined #openwrt-devel
<stintel>
ugh, I'm gonna have to buy an apple homepod or apple tv 4k 128GB to be able to upgrade these eve device firmwares to the one with thread :/
goliath has quit [Quit: SIGSEGV]
minimal has quit [Quit: Leaving]
<stintel>
I guess we're going to have to write utbr-agent :P
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
srslypascal is now known as Guest18
srslypascal has joined #openwrt-devel
Guest18 has quit [Ping timeout: 480 seconds]
champtar has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
<champtar>
Hi all, I upgraded yesterday my Turris Omnia from 22.03 to master with 5.15 kernel, and I now get tagged packet out of the switch on ports that are configured to send untagged (edited config https://paste.debian.net/hidden/4da5d8ce/)
<champtar>
vlan 2 is my private vlan, vlan3 my iot vlan, tcpdump on a laptop connected to lan4 (supposed to send only vlan2 untagged) I see packets tagged with vlan2 and vlan3 ...
<champtar>
Devices on wifi works, wired devices works, wifi to wired is broken
<champtar>
I'm not following the ML closely, but I thought Turris Omnia was supposed to work in master / kernel 5.15, is it still known broken ?
<stintel>
why the * at the end of lanX:u ?
<stintel>
also, verify with `bridge vlan` if that matches what is in your config
<champtar>
I can try without, it was ok in 22.03
<stintel>
other than that my config looks similar and works (not mvebu though)
<stintel>
but check `bridge vlan` output
<stintel>
ergh
<stintel>
it's 6 in the morning, I should probably go to bed
<dwfreed>
lol
<dwfreed>
sleep is for the weak
<champtar>
I don't have the bridge command ... maybe that's the problem
<stintel>
it should work without, but that's invaluable for verifying things, imo
<champtar>
(doing a clean build, will have bridge soon)
<stintel>
hmmm some of my ikea zigbee lamps acted up on restarting otbr-agent
<stintel>
that shouldn't happen :P
<stintel>
have to say, this olinuxino booting from the eMMC ... soooooo much better than whatever else with uSD
chuck4888 has quit [Remote host closed the connection]
csrf has quit [Quit: Leaving]
<f00b4r0>
heh, client of mine needs telnet on devices, not enough space to install the telnet-bsd package. *sigh*
<dwfreed>
busybox telnet?
<f00b4r0>
yes, except it requires rebuilding busybox and we're using imagebuilder.
<dwfreed>
oof
<f00b4r0>
really wish #10462 was accepted
<jow>
please not
<f00b4r0>
please not what?
<jow>
no telnt client by default, it's just a waste of space
<f00b4r0>
it uses < 1KB
<Znevna>
"here, use SSH, better"
<f00b4r0>
i've actually *checked* that
<f00b4r0>
in fact, for most images, thanks to squashfs compression + padding, there is no change in final image size
<f00b4r0>
Znevna: not always an option
<f00b4r0>
as explained at length in the PR
<jow>
just because a feature is small does not mean we should include it
<f00b4r0>
I do not understand that argument, I'm sorry.
<f00b4r0>
there are plenty of use cases for it, and the alternative is 30KB of bloat
<jow>
I don't have any
<f00b4r0>
yeah that is unfortunately what I see here: no argument against other that "in the holy name of everything sacred" :P
<jow>
it is fine if you want to see it that way
<f00b4r0>
*¯\_(ツ)_/¯
<Znevna>
go cereal if you can't do telnet :p
<f00b4r0>
I'm not "seeing" it anyway. The size argument is moot (1KB, when our images typically grow by 10x more on every service release), and we're making the life of our users harder. I must be dense but I don't see how that's a good thing.
<jow>
I'm not seeing why we should include features just because they're small and someone might need them
<f00b4r0>
have you read the PR?
<jow>
following that logic and taking the combined needs of everyone, we would simply need to include all features
<jow>
yeah, "I want telnet because my project needs it"
<f00b4r0>
no
<jow>
and "I claim it's useful, everyone needs it"
<jow>
and "I't so small, let's just sneak it in, won't hurt anyone"
<f00b4r0>
I'm happy to learn why we have mkswap, swapon and swapoff on all devices when most of them have no use for it
<jow>
I'd rather drop those then
<jow>
and before a *telnet client* is enabled by default there's features that arguably benefit way more users
<f00b4r0>
jow: the problem has been explained by robimarko and others here before: there are very valid use cases for a telnet client, especially in a world of tiny iot devices
<jow>
like less search
<jow>
there's always a valid usecase for a given feature
<jow>
that alone is not reason enough to enable it
<jow>
there's also valid use cases for doing dns-over-https or mdns by default
<f00b4r0>
what defines "reason enough" is what I don't see here?
<f00b4r0>
hard to argument for or against something when you don't know where the bar is set.
<ynezz>
curl telnet://iot.box.net:23
* ynezz
hides
<f00b4r0>
needs curl, which is even bigger
<ynezz>
what is exactly preventing you from your custom imagebuilder with your desired feature set?
<f00b4r0>
jow: don't get me wrong, but from an external pov it looks completely arbitrary. My client is asking me why busybox telnet client is disabled and whether a case could be made to change that, and I can't answer either question (or for the first: "because they said so")
<jow>
f00b4r0: because there simply is no need a for a majority of users
<Znevna>
what percent of OpenWrt users are gonna touch ssh/telnet in the lifetime of a router?
<jow>
it's an interactive shell client
<f00b4r0>
jow: we could disable 80% of features with that argument
<jow>
you neither need a telnet client to configure the router
<jow>
nor do you need it to transfer files
<jow>
or to connect other openwrt systems
<jow>
it's not needed for the system itself either (init scripting, hitplug scripting ,... )
<jow>
in the majority of cases where interactive telnet is needed to connect a device you can do it fro mthe workstation
<jow>
or in case the device is only reachable by openwrt, do an ssh tunnel or port forward and then from the workstation
<f00b4r0>
except when the "workstation" is running openwrt :)
<jow>
a "workstation" running openwrt not having 30KB to spare for installing a telnet client?
<jow>
this sounds like a highly specific usecase to me that likely won't apply to the majority of users that - for whatever reason - require a telnet client on openwrt
<f00b4r0>
touché
<dwfreed>
yeah, generally they have the space to just opkg install telnet-bsd
<f00b4r0>
I rest my case. But we still have the swap* family on board :)
<jow>
if it's about automating workflows/deployments of iot devices etc. you'll likely also require some aditional scripting around telnet, like expect, lua/awk/bash etc.
<dwfreed>
f00b4r0: probably an oversight in not disabling them
<jow>
I'm all for disabling *swap
<jow>
and enabling less search instead
<dwfreed>
less search would be nice, yes
<f00b4r0>
for less search I use vi
<f00b4r0>
never understood why vi has search and not less, see broken by design
<f00b4r0>
in busybox
<f00b4r0>
seems*
<Habbie>
hah, indeed, on openwrt i often use vi for viewing files because it has search
<f00b4r0>
in fact we should enable the "view" alias :)
jbowen_ has quit [Read error: Network is unreachable]
jbowen_ has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<f00b4r0>
another thing that would be nice then is if the telnet-bsd package could be backported to release. Dunno if that's something usually acceptable mid-cycle
<jow>
I think it is fine
<jow>
it's a leaf package, the sole provider and not affecting existing things
Tapper has joined #openwrt-devel
<f00b4r0>
sounds good. What's the normal way to do this? Should I open a PR?
<jow>
a PR against openwrt-22.03 containing a git cherry-pick -x from master
<f00b4r0>
ok, thanks
<aiyion>
stintel: reads like a productive night on your end. Congratulations on your eMMC boot.
<Borromini>
f00b4r0: i'm curious as to which situation would make telnet offer an advantage over SSH.
<f00b4r0>
Borromini: any device that doesn't have SSH server.
<f00b4r0>
and unfortunately, there are a lot.
<aiyion>
Borromini: Nooo :D It is already dead :D
<f00b4r0>
but yeah, let's not revive this cadaver :)
<Borromini>
f00b4r0: so you're stripping Dropbear from images then
<Borromini>
i'm merely curious, I have no further intentions
<f00b4r0>
no, I'm talking devices that do not run openwrt.
<Borromini>
ok.
<f00b4r0>
think iot, switches, appliances, etc.
<Borromini>
oftc already banned me over the wrong keystroke, so... :P
<Borromini>
ok so you wanted a telnet client not a server, i got that wrong
<aiyion>
lol.
<f00b4r0>
oh yeah, I'd never make the case for a telnet server. I'm not *that* obnoxious :D
<f00b4r0>
(or so I hope :)
<Borromini>
=)
<enyc>
** just asked in #openwrt I've seen squiggledy intermittent misbehaviour with dnsmasq (seemingly) on 22.03.2 and wondering if anybody recognizes intermittent dns lookups
<enyc>
I noticed 22.03 has an updated dnsmasq now, trying that out in advance of 22.03.3
<Borromini>
would it make sense to restrict a dns server to the performance cluster on a big.LITTLE configuration?
lmore377 has joined #openwrt-devel
lmore377_ has quit [Read error: Connection reset by peer]
bjorn has joined #openwrt-devel
<stintel>
aiyion: yes, thank you :)
* stintel
ignores telnet
<aiyion>
It looks like dangole added the support for the first? MT7986A a few weeks back, by adding the BPi-R3
<aiyion>
I'd say I try to backport that like dangole did for the banapi three weeks ago and start regualr device support from there on out?
<mrkiko>
aiyion: on what device are you working?
<aiyion>
mrkiko: brume2
<mrkiko>
aiyion: oh, sorry; I already asked you but forgot the anser. Thanks ! Does it have wi-fi or not (like brume1)
<aiyion>
Got it yesterday, but spent the late afternoon milling the aluminium enclosure to retrofit an external serial console.
<aiyion>
mrkiko: It does not have wifi, which s why I expect it to be feasible ;)
<mrkiko>
aiyion: :D :D
<stintel>
if it would be PoE-PD I would have ordered 2 :P
<mrkiko>
aiyion: it's called mt2500 right?
<stintel>
still looking for something small preferably PoE-PD to do a HA setup at my parents' plac e
<aiyion>
mrkiko: yes. and as far as I can tell, the Variant "A" is the same device, but with aluminium enclosure.
<aiyion>
stintel: is poe to usbc already a thing?
<stintel>
too ugly, then I might as well plug in a power brick :)
<stintel>
PoE-PD is not absolutely required, but I just very much prefer it
<aiyion>
full ack.
<aiyion>
stintel: ubiquitis Edgerouter?
<Borromini>
that's MT7621 no
<aiyion>
The modell X has a similar form factor. Not quite as powerful though.
<stintel>
I got 2 mikrotik something but didn't manage to install openwrt on it yet :P
<aiyion>
Borromini yes, why?
<Borromini>
you got an RB5009 with PoE stintel ? :P
<stintel>
ah my parents have 200/30 or something, plenty for their use case
<stintel>
Borromini: no no :)
<Borromini>
aiyion: just asking/saying, because lots of people seem to want it gone :P
<Borromini>
stintel: awww :P
<stintel>
install instructions don't work, serial console is ... annoying
<stintel>
there are no holes for ttl header in the board
<Borromini>
for the MikroTik you got? :-/
<Borromini>
or for the RB5009
<stintel>
then one I got
<stintel>
rb5009 is way overkill for the use case at my parents
<stintel>
and they wont appreciate me putting 2 m300s there :P
<Borromini>
xD
<Borromini>
'stintel it's a bit noisy'
<stintel>
(in case I'd replace them with 2 rb5009 for here)
<Borromini>
'oh ma that's normal'
<aiyion>
Borromini: thats way ahead of me... I'm coming from germany and am doing a little gluon/freifunk stuff. The people we are dealing with argue about whether ar71xx needs to be gone and whether 4/32 is really *that* hard of a limit...
* aiyion
curls in the corner.
<Borromini>
aiyion: hehe
<Borromini>
i like mt7621. I have quite a few.
<Borromini>
The RB5009UG is pure overkill, but I wasn't paying so I have gone overboard
<stintel>
I like mt7621 too :)
<stintel>
though I gave away my dir860l - because I had only one :P
<Borromini>
:P
<stintel>
devices for production I shall have at least 2
<Borromini>
then thou shalt have two, my friend.
<stintel>
you can still end up in funny situations because you can't always use 2 devices in the exact same way
<Borromini>
:)
<stintel>
but it sure prevents a lot of "ffffffffuuuuuuu yyyyyyyyyy"
<aiyion>
stintel: sorry to nag, but now that your sunxi does boot again, would you review the v2 I submitted? (You already wrapped your head around it; would be a waste to have somebody else do that again)
<mrkiko>
Borromini: sorry, some people would like to see mt7621 gone or did I misunderstand?
<aiyion>
Or did your "can't test" not only mean sunxi, but you would like have the test result from somebody third regarding the nanopi?
<Borromini>
mrkiko: yes because it's lacking headroom with WiFi 6
<stintel>
aiyion: aiyion: yeah, I was looking at the alias solution again, because it appears I might need it to have working wifi on my device
<Borromini>
mrkiko: not unlike the QCA MIPS SoCs, but I haven't seen any 802.11ax devices with those yet (nor am I interested)
ephemer0l has quit [Ping timeout: 480 seconds]
<mrkiko>
Borromini: isn't Netgear WAX202 an mt7621 device with wifi 6 ? yes, I understood you where not interested :D :D
goliath has quit [Quit: SIGSEGV]
<Borromini>
mrkiko: there's plenty of MT7621 AX devices :)
<Borromini>
i have two here (WAX202 and EAP615-Wall)
<mrkiko>
Borromini: sorry, I interpreted the phrase wrongly. :) How does the WAX202 perform'
<Borromini>
if you don't need them to route as well they perform nicely as APs
<mrkiko>
Borromini: thanks
<Borromini>
yw
<mrkiko>
I would be curious to see in what state is the R6220
<f00b4r0>
stintel: I'm curious how you do HA with 2 routers: your uplink is connected to a switch and the switch is connected to both routers, or something cleverer?
<stintel>
f00b4r0: the uplink is a huawei ont with 4 lan ports, bridged
zer0def has joined #openwrt-devel
zer0def has quit []
<stintel>
I was in contact with another ISP for a 2Gbps symmetric connection, asked them if there would be an option to plug in the fiber directly in my 10G switch, but they seem to have forgotten about me
<stintel>
but in that case I would do it as you described - the 10G switch has redundant PSU, I don't expect it to die easily :P
<stintel>
but yes, in both cases there is still a SPOF
zer0def has joined #openwrt-devel
<stintel>
I still find the HA setup invaluable as it allows me to sysupgrade an m300 without noticing much (conntrack table syncing is currently broken so SSH connections die but for non-tech users not really an issue)
<stintel>
so for people who like to fiddle and keep WAF high I recommend it :D
<Borromini>
stintel: proximus?
<stintel>
Vivacom Bulgaria
<Borromini>
i meant at your parents' place. Or no HA setup there?
<stintel>
no HA setup there (yet)
<stintel>
and they've Telenet
<Borromini>
ok
<Borromini>
i should test if the Proximus ONT (I got EDPnet fiber) would allow the same, using the multiple lan ports as a poor man's failover
<stintel>
I got lucky, they claimed I can only use mac address 1 on port 1 and mac address 2 on port 2 but turns out I can just float them to either ports
<stintel>
(mac addresses are registered for static DHCP leases)
<Borromini>
ok :)
<Borromini>
I read Proximus still allows 2 PPPoE sessions, i will be testing that shortly... my brother can't take a separate internet plan in his new office due to building regulations (apartment in the building needs internet, so...)
<Borromini>
sorry, thinking out loud
<f00b4r0>
stintel:
<f00b4r0>
stintel: interesting thanks :) Here I tried using an SFP ONU without much luck sadly
<f00b4r0>
i have a small stock if you need one :D
gch981213 has joined #openwrt-devel
<stintel>
f00b4r0: I'd be very tempted to toy with that but for that same reason I didn't look into getting some :P
<f00b4r0>
heh
<f00b4r0>
it can be rather finicky depending on your ISPs restrictions, as I learnt the hard way
<stintel>
at some point I want to get 2 dark fibers and convince a friend to sell me a /24
<stintel>
but that's for when I buy real estate
<f00b4r0>
lol. That's quite ambitious :)
<stintel>
you can just use the word crazy :P
<f00b4r0>
I try to remain polite :D
<Borromini>
stintel: we're all just waiting till you start your own ISP.
<stintel>
if that ever happens it would be IPv6 only ;)
<Borromini>
xD
<Borromini>
that's right, filter out the n00bs
<aiyion>
stintel: huh, okay. Let me know when I can test your approach. I'd really like to have the device working again :/
<Borromini>
mrkiko: that's optimal though, rather close, line of sight, etc
<Borromini>
but you get an idea
gladiac has quit []
gladiac has joined #openwrt-devel
gladiac has quit []
<Borromini>
that's the EAP615-Wall
<Borromini>
can't check the WAX202 because the WDS to the EAP615 would bottleneck it.
valku has joined #openwrt-devel
<mrkiko>
Borromini: thanks
* f00b4r0
notices #11194, fears it too will make it increasingly difficult to reach older systems from openwrt
<minimal>
f00b4r0: "to reach older systems from openwrt" - isn't this a change to the dropbear *server*, not the client?
<f00b4r0>
well my understanding is that it would affect both
<f00b4r0>
but maybe I'm wrong
<stintel>
aiyion: ok so uEnv-a64.txt already uses uuid :P
jbowen_ has quit []
<stintel>
that's why I can't repro
<aiyion>
yep.
jbowen_ has joined #openwrt-devel
<aiyion>
Thats what I worked towards in the first place.
<aiyion>
Have the similar code in default and in a64
jbowen_ has quit []
jbowen has joined #openwrt-devel
<stintel>
aiyion: sorry, very new to sunxi, totally overlooked this
<aiyion>
no problem, was my first shot with this target.
<aiyion>
We've got a bunch of devices that are rather unuseable right now, and I thought it would be a nice learning opportunity.
<aiyion>
I thought it would be rather unclean to make the nanopi r1 use the a64 file.
<aiyion>
if possible at all; haven't looked deeper into the other parameter
<aiyion>
omitting it broke the build.
Larhzu has quit [Quit: leaving]
Larhzu has joined #openwrt-devel
<stintel>
ups
<stintel>
gh issue template pushed
<mrkiko>
It seems interacting with OpenWrt forum is becoming more and more relevant. It would be nice if feasible via CLI
tlj has joined #openwrt-devel
tlj_ has quit [Ping timeout: 480 seconds]
minimal has quit [Quit: Leaving]
<stintel>
aiyion: karlp: so this is what I probably want to go with in the end, probably exactly aiyion's first submission, sorry for that, please review (especially the commit message) and one final test would be cool :)
<stintel>
cc ynezz ^
<stintel>
once I get the whole external-static-with-rootfs I'll have an attempt at migrating to that - if nobody beats me to it
schwicht has quit [Read error: Connection reset by peer]
ephemer0l has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<aiyion>
stintel: I'm on my way home for christmas. I've packed the NanoPi as well as the Brume2 though, so I should be able to do a test until tomorrow morning.
<stintel>
aiyion: what do you think about changing default env after all (and reasoning in commit message)?
SamantazFox has joined #openwrt-devel
<aiyion>
I think arguing from bananapi is a bigger stretch than from the other nanopi devices in the rockchip target.
<aiyion>
But in the end that does not matter too much.
<aiyion>
But like I said, irrelevant nitpicking. We've fixed this kind of issue in other targets before and have used UUIDs before. After all this should not introduce problems.
<stintel>
aiyion: different target though, not sure if for rockchip we also build and include u-boot everywhere
<stintel>
if there are devices with u-boot on some flash chip, this version might not support the uuid wizardry
<aiyion>
maybe karlp wants to add something.
<aiyion>
yep
<aiyion>
that were his concerns as well.
<stintel>
I went over all of the supported devices in sunxi and either I totally misunderstood something, or all of theme include our self-built u-boot in the image
<aiyion>
Sounds good
<stintel>
alright, let me know once you've done a final test (although I just git mv -f'd), and I'll push
<stintel>
it's master after all, if there's fallout we can revert
<stintel>
if there isn't, we can backport to 22.03 early next year
goliath has joined #openwrt-devel
goliath has quit []
cbeznea has joined #openwrt-devel
floof58 is now known as Guest73
floof58 has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
Guest73 has quit [Ping timeout: 480 seconds]
robimarko has joined #openwrt-devel
goliath has joined #openwrt-devel
dangole_ has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
cmonroe has quit [Ping timeout: 480 seconds]
SlimeyX has quit [Read error: Connection reset by peer]
cbeznea has quit [Quit: Leaving.]
SlimeyX has joined #openwrt-devel
<stintel>
hmmm right, was trying to update uboot-sunxi but ... sysupgrade doesn't upgrade u-boot
<stintel>
because it's not in a partition
<stintel>
next rabbithole :P
<dwfreed>
can't you do a custom upgrade script with sysupgrade?
<stintel>
dd to the rescue :)
<stintel>
I guess sunxi needs some love
tlj has quit [Remote host closed the connection]
<dwfreed>
iirc, the nbg6817 does it to swap the dualboot flag
<stintel>
yeah but we're not using the mmc boot partitions
<stintel>
on sunxi
<dwfreed>
I just meant that as an example of it being possible to do custom things in a script during sysupgrade
<stintel>
sure, you can do per-target, even per device magic
<stintel>
but that's not implemented in 1-2-3
<stintel>
not for this year :)
<stintel>
I just dd'd the u-boot to the right offset and it's fine now
<stintel>
with uboot 2020.07 and trusted-firmware-a 2.8 I'm apparently also no longer seeing the panic after reboot
<stintel>
panic not in kernel but I assume some part of the bootloader
Borromini has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
<karlp>
stintel: aiyion I've not tested 0d22648ae9c but it looks ~equivalent to mine. the key is uising that ${mmc_bootdev}
<karlp>
beyond that, I don't mind. That style, with mmc_bootdev lets you use the same images for installing to sd or to emmc,
<stintel>
ok I'm just going to push it I think
<karlp>
for my own use, I'll be doing a different style, that I'm not sure how upstreamable it will be, which puts uboot on emmc boot partition, and rootfs by itself on the user partition, without any fat cruft.
<karlp>
but that's a different step altoegher
<stintel>
karlp: I want to look into that as well
<karlp>
I'm _pretty_ sure the default for sunxi should be this, because it a) makes no differecne for sd card only devices, and is automatyically better for dual devices.
<stintel>
I'll be making a PR on github too that bumps uboot and trusted-firmware-a
<karlp>
I just didn't have any others to test with.
<stintel>
as long as u-boot supports the uuid probing, but since all sunxi uses our self-built u-boot ...
<stintel>
the only problem I can see is that (in my case at least), u-boot is not upgraded by sysupgrade
<stintel>
target simply needs some more love :)
<karlp>
yeah, I don't have sysupgrade at all right now :)
<karlp>
and I'm ok with not having an easy path for uboot upgrades.
<stintel>
sysupgrade works for me with the sdcard image :D
<stintel>
but without u-boot
<karlp>
honestly, I never tried, because I knew I wanted the different style
<stintel>
now if we can u-boot on boot0/boot1 with fallback .. that would be epic
<karlp>
it's one of the balls still up in the air.
<karlp>
I have uboot on boot0, and then dual environments on boot1, but there's actually heaps of room,.
<stintel>
I saw 4MiB boot0 and boot1
<karlp>
yeah, that's normal
<stintel>
so that should be plenty of room
<karlp>
I've heard of only 2MB, but apparently ~all of them are 4.
<stintel>
maybe someone misread the spec :P
<karlp>
lol
<karlp>
I'm more interested in dual kernel/rootfs than dual uboot though personally :)
Tapper has joined #openwrt-devel
<stintel>
good luck with 4MB :(
<stintel>
but I guess dual u-boot in boot0,boot1 and then multiple partitions for kernel,rootfs A,B could work
<karlp>
I have no horse in the game, but the less patching the better IMO.
<stintel>
totally, I tried dropping the no-binman patch but ran into errors
<stintel>
so ... meh :(
<stintel>
and I'm not sure we want to move the whole python mess from packages feed in core :D
<stintel>
good to know you're working in etactica/openwrt - didn't find much under karlp/openwrt
<stintel>
anyway
<karlp>
well, this is work stuff, so trying to keep it in the right place :)
<stintel>
makes sense
<stintel>
anyway - a few more pokes at openthread-br to see if I can copy an image to my 2nd a64-olinuxino that has only thread connectivity
tlj has joined #openwrt-devel
cmonroe_ has joined #openwrt-devel
Borromini has quit [Quit: leaving]
<SlimeyX>
stintel i dont get the [ 2.825717] fsl_dpaa_mac ffe4e0000.ethernet eth0: init_phy() failed, ip: SIOCSIFFLAGS: No such device,sendto(): Network unreachable messages anymore but communication is still a bust https://paste.ee/p/otAfY
<neggles>
stintel: "On such [sunxi] devices, the mmc device order is unpredictable" <- if the mmc device order is unpredictable, and a mainline or recent U-Boot is in use, the u-boot devicetree for those devices is missing some things
<neggles>
it should be predictable in downstream/tina-linux u-boot as well
<stintel>
neggles: it can be properly fixed later
<stintel>
don't have time now to dig in all that u-boot/dt/... magic
<stintel>
and people are waiting for months to have this resolved
<neggles>
that's fair, and using PARTUUIDs is also totally fair and reasonable
<stintel>
SlimeyX: wrong phy<->mac link, or wrong phy addr
<stintel>
openwrt-sunxi-cortexa53-olimex_a64-olinuxino-emmc-squashfs-sdcard.img.gz 7% 1200KB 9.0KB/s 26:28 ETA
<dwfreed>
oof
<stintel>
fucking a I'm able to transfer an image via scp to my 2nd a64-olinuxino via thread!
<neggles>
zigbee ipv6 go brrr?
<stintel>
no zigbee involved
<stintel>
802.15.4 ;)
<stintel>
but this is exciting
<neggles>
tomato, tomato :P (I know thread isn't zigbee but shhh)
<neggles>
what kernel are we up to in testing these days? I've a few RK3588 devices that could be fun to support but they really need 6.0 or greater :/
<slh>
Ansuel has been working on v6.1 (next LTS), while that isn't merged, it's not too far away
<neggles>
awesome
<neggles>
need to check if my "fix pcie on RK356x/RK3588" patch actually got applied
<stintel>
6.1 will not happen before we branch new release
<neggles>
then either send v2 or send a fix, had a typo, 0x41000000 =/= 0x42000000
<neggles>
stintel: makes sense :) will keep an eye out then
<stintel>
lost connection
<stintel>
oh well
<stintel>
it worked for a while :P
<neggles>
aw
<neggles>
restartable rsync transfer time?
<stintel>
doesn't matter
<stintel>
it was just for testing
<stintel>
ot-ctl netdata publish route 0::/0 s high
<neggles>
PoC complete
<stintel>
this route seems to be dropped after a while
<stintel>
yeah
<stintel>
encouraging to dig deeper
<neggles>
maybe it needs to be repeatedly published?
<stintel>
:P\
<stintel>
already did twice :P
<stintel>
but thread is ... complex
<neggles>
I can see why they wouldn't want a default route to stay valid for very long in a thread network
<stintel>
well the thread network uses ULA prefixes anyway
<stintel>
and I don't have IPv6 NAT on my edge
<stintel>
so will never be a problem ;p
<stintel>
but yeah like you mentioned PoC complete, lots of stuff to think about now